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1 Einleitung 


Ausgangssituation 

An technische Anlagen besteht die Anforderung einer hohen Anlagenverfügbarkeit 
bei gleichzeitig geringen Kosten, welche durch eine zustandsorientierte prädiktive 
Instandhaltung besser erfüllt werden kann. Voraussetzung dafür ist eine frühzeitige 
Erkennung von Ermüdungs- und Verschleißerscheinungen vor dem Ausfall funkti- 
onskritischer Komponenten. Es wird eine hohe Ausnutzung des Abnutzungsvorrats 
eines Funktionselements bei gleichzeitig besser planbaren Wartungs- und Instand- 
haltungsmaßnahmen erreicht. 

Für die Umsetzung einer zustandsorientierten prädiktiven Instandhaltungsstra- 
tegie ist ein geeignetes Messkonzept notwendig, welches durch die Messung pas- 
sender zustandsbeschreibender Merkmale den Zustand der Funktionskomponenten 
erfasst und diese zur Analyse und Darstellung an eine Leitwarte sendet. Ein kabello- 
ses funkbasiertes Messsystem senkt den Installationsaufwand erheblich und ermög- 
licht Messungen auch an schwer zugänglichen Orten. Ein energieautarkes System 
reduziert den Wartungsaufwand, da z.B. Batteriewechsel überflüssig werden. 

Grundlage dieser Bachelorarbeit ist ein solches in einem früheren Projekt ent- 
wickeltes Sensorkonzept. 


Problemstellung 

Die energetische Lebensdauer eines energieautarken Funksensorsystems hängt von 
der hard- und softwaretechnischen Umsetzung des Systems ab. Die Sendeleistung 
des Transceivers beeinflusst den Gesamtenergieverbrauch des Sensorknotens stark. 
Bei dem bestehenden Sensorkonzept werden deshalb zur Verbesserung der Ener- 
gieeffizienz vor allem aufgrund der Sendedauer Optimierungspotenziale vermutet. 


Zielstellung 

Ziel dieser Bachelorarbeit ist die Untersuchung des bestehenden Sensorkonzepts auf 
kommunikationstechnische Optimierungspotentiale zur Verbesserung der Energie- 
effizienz. Die größten Potentiale werden softwareseitig bei der Netzwerkkommuni- 
kation gesehen. Deshalb soll mit der vorhandenen Hardware ein Alternativkonzept 
zur Datenübertragung mittels des leichtgewichtigen Netzwerkkommunikationspro- 
tokolls MQTT (Message Queuing Telemetry Transport) umgesetzt werden. Es soll 
ein Szenario entwickelt werden, welches vergleichbar mit dem bestehenden Sen- 
sorkonzept ist, um eine objektive Bewertung der Veränderung der Energieeffizienz 
durchführen zu können. Dazu ist es notwendig, eine messtechnische Strategie zur 
Bestimmung der Sendedauer und des Energieverbrauchs zu erstellen. 
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2 Einleitung 


Lösungsansatz 

Es werden zunächst die Anwendungsmöglichkeiten solcher Sensorsysteme in den 
bestehenden Instandhaltungsstrategien beschrieben, sich dafür grundsätzlich eig- 
nende Messprinzipien und zustandsbeschreibende Merkmale erarbeitet, sowie auf 
bestehende Projekte eingegangen. Anschließend erfolgt die Analyse des bisherigen 
Sensorkonzepts, auf deren Basis mit der vorhandenen Hardware ein Alternativkon- 
zept zur kommunikationstechnischen Optimierung realisiert wird. Zudem wird ein 
Messkonzept zur Bestimmung der Sendedauer entwickelt, welches einen Vergleich 
mit dem bestehenden Sensorkonzept ermöglicht. Es kann somit eingeschätzt wer- 
den, inwieweit die Zielstellung erreicht wurde. 


2 Stand der Technik 


Funkbasierte Sensorsysteme ermöglichen eine Überwachung von Systemen und 
Anlagen, die mit der herkömmlichen kabelgebundenen Technik vor allem bei 
schwer zugänglichen Funktionselementen aufgrund des hohen Installationsauf- 
wandes nicht wirtschaftlich realisierbar wäre. Dies schafft neue Möglichkeiten im 
Bereich der Instandhaltung, da die Kosten für die Überwachung von Prozessen und 
Anlagen sinken. Zudem können Daten derart erfasst und ausgewertet werden, dass 
sich der Ausfall einer Funktionseinheit vorherbestimmen lässt. Im Folgenden wird 
einführend auf Strategien der Instandhaltung und die sich daraus ergebenden Ein- 
satzmöglichkeiten solcher Sensorsysteme eingegangen. Ferner werden die Grund- 
lagen der dafür benötigten zustandsbeschreibenden Merkmale und messtechni- 
schen Prinzipien dargelegt und kurz auf bestehende Projekte an der Professur für 
Industrielle Messtechnik an der HTWK in diesem Bereich eingegangen. 


Instandhaltungsstrategien 

Der Einsatz technischer Maschinen und Anlagen führt aufgrund chemischer und 
physikalischer Vorgänge zu natürlicher Abnutzung. Dazu zählen u.a. mechanischer 
Verschleiß, Korrosion, Alterung und Ermüdung. Jede Maschine und Anlage, aber 
auch jedes einzelne Bauelement verfügt über einen individuellen Abnutzungsvor- 
rat, der den Vorrat möglicher Funktionserfüllungen darstellt. Bei Erstinbetrieb- 
nahme liegt der Abnutzungsvorrat bei 100%. Dieser sinkt infolge der Abnutzung 
während des Betriebes. Aufgabe der Instandhaltung ist es sicherzustellen, dass der 
Abnutzungsvorrat einer Einheit über der individuellen Abnutzungsgrenze liegt. 
Diese drückt sich z.B. in zunehmenden Ausschuss, technischen Schäden oder den 
Ausfall der Einheit aus. Die Instandhaltung besitzt damit Einfluss auf die Qualität 
des Produktionsprozesses und der Produkte. [71] 

In modernen Produktionskonzepten erfolgt keine Unterteilung mehr in 
Haupt- und Nebenprozesse. Die Instandhaltung wird damit zu einer unterneh- 
mensübergreifenden Aufgabe, welche zu einer effizienten Produktion beiträgt. In 
Organisationskonzepten wie z.B. der TPM (Total Produktive Management) ist die 
Instandhaltung ein Teil der Ansatzpunkte, um Verschwendungen und Verluste zu 
reduzieren und eine möglichst hohe Anlageneffizienz zu erreichen. [45] [60] 

Durch die Instandhaltung erfolgt der Erhalt der Funktions- und Leistungsfähig- 
keit einer technischen Einheit. Um dies umzusetzen, gibt es einige grundlegende 
Strategien der Instandhaltung, die den Zeitpunkt und die Art der Maßnahmen 
regeln. Bei der Auswahl einer geeigneten Strategie spielen gesetzliche, sicherheits- 
relevante, technische, produktionsrelevante und wirtschaftliche Aspekte eine Rolle. 
[60] Da je nach Anwendungsfall unterschiedliche Voraussetzungen, Zusammen- 
hänge und Konsequenzen eines Ausfalls bestehen, gibt es nicht die eine geeignete 
Instandhaltungsstrategie, sondern der Einsatz muss individuell betrachtet werden. 
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4 Stand der Technik 


Instandhaltungs- 
strategien 


Reaktive Präventive 


Instandhaltung Instandhaltung 


periodisch 


vorbeugend zustandsabhängig vorausschauend 


Abb. 1 Instandhaltungsstrategien [60] 


In [60] wird die in Abbildung 1 aufgezeigte Unterscheidung in zwei Grundstrategien 
vorgenommen - der reaktiven und der praventiven Instandhaltung. 

Bei der reaktiven Instandhaltung wird der Abnutzungsvorrat vollstandig ausge- 
nutzt, da eine Reaktion der Instandhaltung erst nach Ausfall einer Komponente statt- 
findet. Aufgrund des damit verbundenen Unfallrisikos und Gefahrdungspotentials 
oder erwartbarer Folgeschaden anderer Anlagenteile kann diese Strategie im Einzel- 
fall unzulässig sein. Zumeist tritt der Schadensfall plötzlich ein, sodass eine Planung 
von Instandhaltungsmaßnahmen nicht möglich ist und die benötigten Instandhal- 
tungsressourcen entweder extra vorgehalten werden müssen oder im Zweifelsfall 
nicht vorhanden sind. Dies führt im Vergleich mit anderen Strategien zu den höchs- 
ten Ausfallzeiten und den höchsten Ausfallfolgekosten. Dadurch ist eine empfehlens- 
werte Anwendung auf Anlagen mit redundanten Systemen oder einer schnellen Scha- 
densbehebung beschränkt, die keine Sicherheitsanforderungen erfüllen müssen und 
deren Ausfall keine Unterbrechung der Produktion bewirkt. [60] 

Dem gegenüber stehen präventive Instandhaltungsstrategien, bei denen Mafsnah- 
men vor Eintreten des Schadensfalls getroffen werden. Der Zeitpunkt des Einsatzes 
dieser Maßnahmen wird entweder periodisch vorbeugend, zustandsabhängig oder 
vorausschauend bestimmt. [60] 

Bei der präventiv-periodisch vorbeugenden Instandhaltungsstrategie wird die 
Komponente unabhängig von ihrem Zustand nach definierten Nutzungsintervallen 
instandgesetzt oder ausgetauscht. Diese Intervalle werden entweder zeitbezogen 
zu festgelegten Zeitpunkten bzw. nach einer definierten Anzahl von Betriebsstun- 
den oder aber ereignisbezogen z.B. nach Stückzahlen oder gefahrenen Kilometern 
bestimmt. Vorteile dieser Strategie sind eine gute Planbarkeit der Instandhaltungs- 
maßnahmen sowie ein geringes Ausfallrisiko. Allerdings wird der Austausch der 
Komponenten zumeist vor Ausnutzung ihrer Abnutzungsvorräte erfolgen, sodass 
der Verbrauch von Materialien erhöht wird. Voraussetzung für diese Strategie ist 
eine gute Prognose über die zu erwartende Lebensdauer der Funktionselemente. 


Stand der Technik 5 


Sonst entstehen entweder hohe Vorbeugungskosten durch die mangelhafte Aus- 
nutzung der Abnutzungsvorräte oder ein Ausfall der Einheit erfolgt frühzeitiger als 
vorhergesagt, was zu den Folgen der reaktiven Instandhaltungsstrategie führt. [60] 

Die zustandsabhängige Instandhaltungsstrategie setzt bei dem Nachteil des 
unzureichend ausgenutzten Abnutzungsvorrats an. Statt wie bei der periodisch vor- 
beugenden Instandhaltung nach starren Nutzungsintervallen vorzugehen, ist die 
Steuergröße zum Einleiten von Instandhaltungsmaßnahmen der Zustand der zu 
betrachtenden Einheit. Voraussetzung dafür sind aktuelle Zustandsinformationen 
der Anlage, die Rückschlüsse auf die Veränderung des Abnutzungsvorrats zulas- 
sen und deren Erfassung mit wirtschaftlich vertretbaren Aufwand erfolgen kann. 
Diese zustandsbestimmenden Parameter können entweder durch Inspektionen, bei 
denen durch den Menschen zustandsrelevante Parameter erfasst und bewertet wer- 
den oder mit technischer Unterstützung durch Systeme zur Zustandsüberwachung 
gewonnen werden. In Abhängigkeit von den geeigneten zustandsbeschreibenden 
Merkmalen gibt es verschiedene Messprinzipien und -systeme, worauf im Laufe 
dieses Kapitels näher eingegangen wird. [60] 

Im Vergleich zur vorbeugenden Instandhaltungsstrategie wird der Abnutzungs- 
vorrat der technischen Einheit erheblich besser ausgenutzt, da Instandhaltungs- 
maßnahmen auf Basis des Zustandes und nicht aufgrund von Erfahrungswerten 
oder statistischer Auswertungen eingeleitet werden. Auch kann ein frühzeitiger als 
erwartet erfolgter Ausfall von Komponenten erkannt werden, wodurch die Zuver- 
lässigkeit und Verfügbarkeit der Anlagen steigt. Allerdings fallen Mehrkosten für 
die notwendigen Überwachungs- und Diagnosesysteme an und die Überwachung 
der Einheiten muss mit geeigneten Zustandsparametern, Messtellen und Sensoren 
überhaupt prinzipiell und mit einem vertretbaren Aufwand möglich sein. [71] 

Die vorausschauende Instandhaltung setzt gegenüber der zustandsabhängigen 
Strategie noch deutlich eher an. Ziel ist es, bereits potenzielle Störungen zu erken- 
nen und entweder deren Weiterentwicklung gezielt zu verhindern oder den Aus- 
fall möglichst frühzeitig vorauszusagen und damit eine bessere Einplanung der 
Instandhaltungsmaßnahmen in den Produktionsplan zu ermöglichen. Vorausset- 
zung dafür sind eine statistisch relevante Datenbasis an Zustandsinformationen und 
Ausfällen mit den damit verbundenen Zustandsparametern sowie die Kenntnis über 
die Ausfallzusammenhänge. Langfristig gedacht ermöglichen die daraus gewonne- 
nen Erkenntnisse auch Maßnahmen wie bspw. konstruktive Änderungen, welche 
die Lebensdauer der betrachteten Einheit verlängern. [68] 


Messtechnische Prinzipien und zustandsbeschreibende Merkmale 

Die Daten, die eine Zustandsüberwachung für die zustandsabhängige und voraus- 
schauende Instandhaltung ermöglichen, müssen auf eine sinnvolle Weise gewon- 
nen werden. Dafür ist es notwendig, geeignete Merkmale zu finden, die den Zustand 
einer Einheit beschreiben, Rückschlüsse auf kommende Ausfälle zulassen und sich 
messtechnisch mit vertretbarem Aufwand erfassen lassen. Solche Merkmale stellen 
physikalischer Größen wie z.B. Schwingungen und Temperaturen sowie Verschleiß- 
und Schmierzustände dar. [51] 
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Weit verbreitet ist die Schwingungsdiagnose, mit der die Messgröße Körperschall 
überwacht wird. Schwingungssensoren erfassen das durch Betrieb der Anlage 
entstehende Schwingungssignal. Dieses wird auf seine Zusammensetzung aus Ein- 
zelsignalen hin z.B. mittels FFT-Analyse (FFT - Fast Fourier-Transformation) unter- 
sucht. So können charakteristische Frequenzen identifiziert werden, welche bei 
ungeschädigten Anlagen nicht auftreten und Rückschlüsse auf den Anlagenzustand 
gewonnen werden. [60] 

Wenn Zustandsveränderungen der Anlage durch thermische Beanspruchungen 
hervorgerufen werden, kann eine Temperaturüberwachung sinnvoll sein. Diese 
erfolgt berührend durch Temperatursensoren an einzelnen Messpunkten oder 
berührungslos durch Thermografie von ganzen Anlagenabschnitten. [60] 

Eine weitere Möglichkeit der Anlagenüberwachung stellt die Analyse von Ölzu- 
ständen dar. Abriebsensoren können Metallpartikel in Hydraulik- und Schmiersys- 
temen feststellen und eine Unterscheidung in Eisen- und Nichteisenabrieb vorneh- 
men. So können mit Trendmessungen Rückschlüsse auf den Verschleißzustand der 
Bauteile in diesen Systemen gewonnen werden. [51] 


Erfassung und Verarbeitung der Messdaten 

Die klassische Verfahrensweise zur Erfassung und Verarbeitung von Messdaten 
stellt zum heutigen Zeitpunkt die folgend beschriebene Messkette dar. Ein Sensor 
setzt die zu messende Größe in eine Spannung um, welche anschließend verstärkt 
wird. Eine Messkarte dient als Schnittstelle zwischen der Sensorik und einem Aus- 
werterechner. Der Rechner kann über die Messkarte Einstellungen an die Sensorik 
übermitteln und die Messung auslösen. Sie digitalisiert zudem die Messwerte und 
ermöglicht damit eine Verarbeitung und Anzeige mittels einer Software auf dem 
Auswerterechner. Der Bediener des Messsystems nimmt die Analyse und Bewer- 
tung der Messwerte vor. [8] 

Herkömmlich erfolgt die Übertragung der Daten zu dem Analyserechner kabel- 
gebunden. Es besteht die Möglichkeit, die Messdaten mithilfe eines Transmittermo- 
duls kabellos vom Sensor zur Auswerteeinheit zu übermitteln. Dies vereinfacht die 
Messung an schwer zugänglichen Orten und erspart eine Verkabelung. Durch den 
Einsatz von Energie-Harvestern, die Energie aus ihrer Umgebung entnehmen, kann 
eine solche Einheit auch energieautark betrieben werden, was u.a. Wartungsarbei- 
ten in Form von Batteriewechseln überflüssig macht. So bietet z.B. das Energie- und 
Automatisierungstechnikunternehmen ABB seit 2017 ein Sensorsystem an, welches 
direkt und ohne Verkabelung am Gehäuse bestehender Niederspannungsmoto- 
ren und Pumpen angebracht wird. Es liefert Zustandsinformationen auf Basis von 
Schwingungs- und Temperaturmessungen und überträgt die Daten über BLE (Blue- 
tooth Low Energy) an das Smartphone des Anwenders. In einer von ABB bereitge- 
stellten App erfolgen eine Visualisierung der Informationen und Handlungsemp- 
fehlungen zur Instandhaltung. [2] 


Bisherige Projekte 
Zu diesem Themenkomplex der zustandsabhängigen und vorrauschauenden 
Instandhaltung mithilfe energieautarker drahtloser Sensorsysteme wurde in der 
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Vergangenheit an der Professur für Industrielle Messtechnik an der HTWK das Pro- 
jekt TRAINCON realisiert. 

Das Ziel dieses Projektes bestand in der Zustandsüberwachung von Bauteilen 
schienengebundener Fahrzeuge wie z.B. Wälzlagern. Es sollen Ermüdungs- und 
Verschleißprozesse vor Ausfall der Komponenten erkannt werden, wodurch im 
Rahmen einer zustandsabhängigen oder vorausschauenden Instandhaltung ein- 
gegriffen werden kann. Es wurde ein funkbasiertes, energieautarkes Sensorsystem 
entwickelt, welches die zustandsbeschreibenden Parameter an eine Basisstation 
sendet. In dieser erfolgt eine Analyse der Daten mit Methoden der kennlinienori- 
entierten Auswertung sowie der unscharfen Fuzzy-Klassifikation. Zudem wird eine 
automatisierte Entscheidungsfindung zur zustandsabhängigen Instandhaltung 
ermöglicht. [78] [36] 

Diese Bachelorarbeit basiert auf dem Sensorsystem des Projektes TRAINCON 
und führt eine Untersuchung hinsichtlich kommunikationstechnischer Optimie- 
rungsmöglichkeiten durch. Eine nähere Betrachtung des Sensor- und Sendekon- 
zepts und der dazu verwendeten Hardware erfolgt in Kapitel 3. 

Aktuell wird das Projekt SmartTram realisiert, im Rahmen dessen auf der Basis 
von Schwingungs- und Ultraschallmessungen ein Mess- und Sensorsystem zur Dia- 
gnose von Straßenbahn-Komponenten entwickelt wird. Dieses ist nicht an die Stra- 
ßenbahn gebunden. Unterstützt durch Simulationen wird eine Früherkennung von 
Abnutzungserscheinungen ermöglicht, welche die Grundlage für eine vorausschau- 
ende Instandhaltung bilden. [37] 


3 Gegenstand der Untersuchung 


In diesem Kapitel wird das bestehende Sensorkonzept analysiert. Es erfolgt eine 
Erläuterung der Hardware und Aufgaben der verschiedenen Komponenten in 3.1 
sowie der Netzwerkkommunikation in 3.2. In 3.3 wird das Zusammenwirken der 
Komponenten als messtechnischem Basiskonzept vorgestellt. Eine Gesamtener- 
giebilanz wird in 3.4 aufgestellt, auf deren Basis Optimierungspotentiale abgeleitet 
werden. 


3.1 Verwendete Hardwarekomponenten 
3.1.1 Kommunikationszentrum und Zentralorgan des Sensornetzwerks 


Der in Abbildung 2 in einer Variante ohne Gehäuse dargestellte Raspberry Pi 2 (RPI) 
ist mit einem Preis von ca. 35€ ein günstiger Einplatinenrechner und hat etwa die 
Grundfläche einer Kreditkarte. Er besitzt einen Quad-Core-Prozessor mit einer Takt- 
frequenz von 900 MHz und 1GB Arbeitsspeicher und weist damit Leistungsdaten 
leicht unterhalb eines günstigen Smartphones auf. Bspw. besitzt das Motorola Moto 
C zum Preis von etwa 70€ einen Quad-Core-Prozessor mit 1,1 GHz Taktfrequenz und 
1GB Arbeitsspeicher. Der RPI enthält keine fest eingebaute Speichereinheit, sondern 
einen MicroSD-Karten-Steckplatz, in dem eine Speicherkarte mit dem Betriebssys- 
tem eingesteckt wird. Als Betriebssystem wird die an den Raspberry Pi angepasste 
Linux-Distribution Raspbian verwendet. Als Schnittstellen stehen u.a. vier USB-2.0- 
Buchsen, ein Videoausgang über HDMI z.B. zum Anschließen an einen Bildschirm, 
je eine 3,5mm-Klinkenbuchse für Stereoaudio- und Composite-Video-Ausgang sowie 
eine 40-polige GPIO-Stiftleiste zur Verfügung. [21] GPIOs (General Purpose Input 
Output) sind programmierbare Ein- und Ausgänge, welche als Schnittstelle zu ande- 
ren Systemen bspw. zur Datenübertragung oder zum Ansteuern von LEDs genutzt 
werden können und teilweise mit speziellen Funktionen versehen sind. [22] Der RPI 
besitzt kein integriertes WLAN-Modul, sodass für das hier betrachtete Einsatzszena- 
rio ein in einer USB-Schnittstelle eingesteckter WLAN-Dongle benötigt wird. 


Abb. 2 Raspberry Pi 2 [21] 


http://doi.org/10.33968/9783966270069.0003 
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Eine Aufgabe des Raspberry Pi stellt der Aufbau eines WLANs dar. WLAN (Wire- 
less Local Area Network) ist ein drahtloses lokales Netzwerk, über welches Daten 
mittels Funk über einer Reichweite von etwa 70 m übertragen werden können. Der 
RPI nimmt die Funktion eines Routers ein. Ein Router ist ein Gerät, welches Daten- 
pakete weiterleitet. Trifft ein Datenpaket ein, schlägt er in einer sog. Routingtabelle 
den besten Weg zum Ziel des Pakets nach und leitet es an die ermittelte Schnitt- 
stelle weiter. Es wird eine Datenübertragung zwischen den sich in diesem Netzwerk 
befindlichen Geräten ermöglicht. Zudem werden Filter- und Firewall-Funktionen 
übernommen, welche vor ungewollten Netzwerkzugriffen schützen. Zusätzlich 
dienen Router zumeist zur Anbindung des Internets an das lokale Netzwerk. Diese 
Funktion wird im vorliegenden Sensorkonzept nicht genutzt. Die Kommunikation 
erfolgt ausschließlich über das lokale Netzwerk. [11] 

Der Raspberry Pi übernimmt zudem eine zweite Funktion und dient als Web- 
server. Ein Webserver übermittelt auf Anfrage Dokumente, z.B. Bestandteile einer 
Webseite, an den anfragenden Client. Als Client wird eine Anwendung bezeichnet, 
welche mit einem Server kommuniziert. Er ist beispielsweise ein Webbrowser, der 
die angefragten Informationen interpretiert und anschließend als Webseite anzeigt. 
Ein Webserver kann zudem zur Verschlüsselung der Server-Client-Kommunikation 
und zur Zugriffsbeschränkung eingesetzt werden, bei der sich ein Client für Zugriffe 
authentifizieren muss. [1] 

Die Realisierung des Webservers auf dem RPI erfolgt mittels der kostenfreien 
Software Apache, welche 2017 bei etwa 46 % aller aktiven Webseiten eingesetzt 
wurde. [49] Apache unterstützt eine Vielzahl von Modulen wie bspw. Schnittstellen 
zu Skriptsprachen wie z.B. PHP (Personal Homepage) oder Verschlüsselungs- und 
Authentifizierungsmodule, welche die Kernfunktion des Webservers erweitern. 
Wie viele Anfragen gleichzeitig der Webserver bearbeiten kann, ist abhängig vom 
Arbeitsspeicher des Webservers. Ist die maximal mögliche Anfragenanzahl über- 
schritten und der Arbeitsspeicher vollständig ausgelastet, stürzt der Webserver ab. 
Um dies zu verhindern, wird mit der Standardkonfiguration von Apache die maxi- 
male Anzahl anfragender Clients auf 256 begrenzt. [35] [46] 

Als Basissprache zur Erstellung einer Webseite dient HTML (Hypertext Mar- 
kup Language), womit der strukturelle Aufbau einer Webseite festgelegt wird. Durch 
Einbindung von CSS-Dokumenten (Cascading Style Sheets) werden Layout, Farben, 
Schriftgrößen usw. bestimmt. In ein HTML-Dokument lässt sich die Skriptsprache PHP 
einbinden, deren Programmcode auf dem Server ausgeführt wird. Es wird die Erstel- 
lung eines dynamischen Inhalts ermöglicht, der in dem Moment der Anfrage vom Cli- 
ent durch Aufrufen des PHP-Skriptes erzeugt wird. Zudem können durch Nutzereinga- 
ben erhaltene Daten mittels PHP verarbeitet und abgespeichert werden. [6] [54] 

Im bestehenden Sensorkonzept wurde mittels eines Editors eine lokale Home- 
page erstellt. Es erfolgte keine Verwendung eines CSS-Dokuments, da das Aussehen 
der Webseite für den Einsatzzweck nicht relevant ist. Der Webserver gibt im Netz- 
werk ein PHP-Skript frei, mit dem das Abspeichern der Messdaten in eine CSV-Datei 
(CSV - comma-separated values) erfolgt. Eine CSV-Datei ist eine Textdatei, in der 
Daten von Kommas und Zeilenumbrüchen getrennt gespeichert werden. 
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3.1.2 Leitwarte 


Bei der Leitwarte handelt es sich um einen Laptop. Die Verarbeitung und Visua- 
lisierung der Messdaten wird auf der Leitwarte mittels einer Matlab-Applikation 
durchgeführt. Matlab ist eine lizenzpflichtige Software, die vor allem zum Lösen 
mathematischer Probleme auf Basis numerischer Berechnungen, zur grafischen 
Darstellung der Lösungen sowie zur Datenerfassung, -analyse und -auswertung ver- 
wendet wird. [30] 

Die mit der Leitwarte erzeugte Visualisierung zeigt Abbildung 3. Es werden aus 
dem Beschleunigungssignal die Spitzen- und Effektivwerte berechnet und mit die- 
sen durch Multiplikation der Diagnosekennwert k(t) gebildet. Es erfolgt die Anzeige 
des Zeitsignals der Messwerte. Über eine Fast-Fourier-Transformation (FFT) wird 
zudem aus dem Zeitsignal das Frequenzspektrum der Schwingbeschleunigung 
berechnet. Auf Basis des Frequenzspektrums können Rückschlüsse auf den Bauteil- 
zustand gezogen werden, da Schädigungen zu charakteristischen Veränderungen 
des Frequenzspektrums führen. Es wird eine Diagnose- und Handlungsempfehlung 
in Ampelform gegeben. Den Ampelfarben liegen definierte Amplitudenwerte der 
Schwingbeschleunigung zu Grunde. Bei Überschreitung der hinterlegten Amplitu- 
denwerte färbt sich die Ampel gelb bzw. rot. Gelb steht für einen auffälligen Maschi- 
nenzustand, rot für einen kritischen. 
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Abb. 3 Visualisierung der kennwertorientierten Zustandsdiagnose auf der Leitwarte [58] 


3.1.3 Sensorknoten 


Die Aufgabe der in Abbildung 4 dargestellten Einheit Sensorknoten besteht in der 
Aufnahme von Beschleunigungsmesswerten durch einen Sensor und dem Versenden 
dieser Werte durch ein Transceivermodul an den Webserver. Die Energieversorgung 
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Abb.4 Bestandteile Sensorknoten [58] 


übernimmt ein Vibrations-Harvester, welcher ungenutzte Vibrationsenergie aus der 
Umgebung des Sensorknotens gewinnt und einen Lithium-Polymer-Akku speist. 


Beschleunigungssensor 

Zum Messen der Schwingbeschleunigung wird der in Abbildung 5 zu sehende Sen- 
sor ADIS 16223 von Analog Devices eingesetzt, welcher ein kapazitiver triaxialer 
MEMS-Beschleunigungssensor ist. MEMS steht für mikroelektromechanische Sys- 
teme. Dies ist ein Überbegriff für miniaturisierte Systeme, welche mechanische und 
elektronische Komponenten mit Abmessungen im Mikrometerbereich in einem 
Bauteil vereinen. Der Sensor weist Abmessungen von (1,5 x 1,5 x 1,5) cm auf, was 
einer platzsparenden Ausführung des Sensorknotens entgegenkommt. [4] 


Abb.5 Beschleunigungssensor ADIS 16223 [eigene Aufnahme] 
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Den prinzipiellen Aufbau eines kapazitiven MEMS-Beschleunigungssensor zeigt 
Abbildung 6. Grundlage eines solchen Sensors ist ein seismisches Feder-Masse- 
System, bei dem ein beweglicher Rahmen eine elastisch aufgehängte Masse bildet 
und mit einer Platte eines Differentialkondensators verbunden ist. Diese Platte istin 
Abbildung 6 mit ® bezeichnet. Die anderen Platten (©) sind fest mit dem Gehäuse 
verbunden. Sie bilden zusammen mit der beweglichen Platte zwei Plattenkonden- 
satoren mit den Kapazitäten C, und C,, welche zusammen einen Differentialkon- 
densator darstellen. Zwischen den Elektroden befindet sich ein Dielektrikum. Der 
Plattenabstand d, zwischen ® und ® eines Kondensators verringert sich um dem 
gleichen Betrag Ad, wie sich der Abstand des anderen vergrößert. Erfährt der Sen- 
sor eine Beschleunigung, ändern sich die Kapazitäten der beiden Kondensatoren 
symmetrisch, da folgender Zusammenhang zwischen Kapazität und Plattenabstand 
besteht [7] [29]: 


era 
1a. [67 (3.1) 
dtd 
Giz Kapazität Plattenkondensator 1 bzw. 2 
E .. Permittivität 
A .. Flächeninhalt der Kondensatorplatten 
d, Plattenabstand im unbeschleunigten System 
d Änderung des Plattenabstandes durch einwirkende Beschleunigung 
Anker 
Ve 
Platten- Beweglicher 
kondensatoren Rahmen 
N —— Mrixierte 
Bo ; ® Platten 
E — | 
p= 
F Differential- 
5 kondensator 
a Differential- 
kondensator 


Anker 


Abb. 6 prinzipieller Aufbau kapazitives MEMS-Beschleunigungssensor-Element nach [4] 
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Diese gegensinnige Kapazitätsänderung lässt sich mit einer Brückenschaltung aus- 
werten. Es wird eine Spannung erzeugt, die proportional zur Auslenkung Ad und 
damit zu der die Masse beschleunigenden Kraft ist. Die Kapazitäten dieser Differen- 
tialkondensatoren liegen im Bereich von Picofarad (10), die Kapazitätsänderun- 
gen im Bereich einiger Femtofarad (10°). [70] 

Der eingesetzte Beschleunigungssensor ADIS 16223 besitzt für jede der drei Ach- 
sen einen kapazitiven MEMS-Beschleunigungsaufnehmer, welche jeweils eine Mes- 
sung im Bereich von -70 g bis +70 g mit einer Abtastrate von bis zu 72,9 kSPS (72.900 
Abtastvorgänge pro Sekunde) ermöglichen. Der Sensor benötigt eine Betriebsspan- 
nung zwischen 3,15V und 3,6V. Er verbraucht im arbeitenden Zustand bei 3,3 V 
43 mA und kann nach einer Messung in einen stromsparenden Sleep-Modus ver- 
setzt werden, bei welchem 230 pA fließen. [4] 

Abbildung 7 zeigt den vereinfachten Aufbau der Signalverarbeitung. Die Kom- 
munikation zwischen Sensor und Transceivermodul erfolgt über ein SPI-Interface. 
SPI ist ein Bussystem zur synchronen seriellen Datenübertragung mit vier Kanälen, 
welche in Abbildung 7 zu erkennen sind. Das Chip Select-Signal (CS) aktiviert die 
Kommunikation, die Serial Clock (SCLK) synchronisiert die Datenübertragung und 
über die DIN- (Data Input) sowie DOUT-Kanäle (Data Output) erfolgt der direkte Aus- 
tausch von binären Informationen mittels 16-Bit-Sequenzen. Die SPI-Schnittstelle 
dient weiterhin zur Übertragung von Filtereinstellungen zum Sensor, zum Aufwe- 
cken des Sensors aus dem Sleep-Modus und zur Auslösung einer Messung. [4] 
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Abb.7 vereinfachte Übersicht der Signalverarbeitung des ADIS 16223 [4] 


Das Auslösen einer Messung kann zudem optional über ein binäres Signal erfol- 
gen, welches vom Transceivermodul ausgekoppelt und am Sensormodul einge- 
lesen wird. Der Sensor verfügt dazu über zwei konfigurierbare GPIO-Anschlüsse. 
Ein zeit- oder ereignisgesteuertes Auslösen der Messdatenerfassung ist ebenfalls 
möglich. [4] 

Das analoge Spannungssignal des kapazitiven Messaufnehmers wird nach dem 
Auslösen einer Messung durch einen integrierten 16-Bit-Analog-Digital-Wandler 
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(engl. Analog-Digital-Converter - ADC) in diskrete digitale Werte umgewandelt. 
Diese Werte werden vom integrierten Controller verarbeitet und im Erfassungs- 
puffer (engl. Capture-Buffer) zwischengespeichert. Durch Ansprechen des Output- 
Registers können die digitalen Beschleunigungswerte ausgelesen werden. Für jede 
Achse existiert ein Capture-Buffer, welcher 1024 Werte zwischenspeichern kann. 
Optional kann der sog. extended-Modus aktiviert werden, wodurch die Capture- 
Buffer der anderen Achsen mitgenutzt und so für eine Achse 3072 anstatt 1024 Werte 
zwischengespeichert und ausgelesen werden. [4] 


WLAN-Transceivermodul 

Es wird als Transceivermodul der Microcontroller ESP8266 eingesetzt, welcher 
einen 32-Bit-Prozessor mit einer Taktfrequenz von 80 MHz besitzt. Das integrierte 
WLAN-Modul erlaubt als WLAN-Station einen drahtlosen Versand von Nachrichten. 
Es kann zudem als Access Point dienen, welcher als Netzwerkknoten das Netzwerk 
erweitert und die Reichweite vergrößert. Es ermöglicht den Zugang für andere End- 
geräte zum WLAN und damit ein sog. vermaschtes Netzwerk. Der verwendete Micro- 
controller beinhaltet 4 MByte internen Speicher und etwa 50 kByte Arbeitsspeicher. 
Der begrenzte Speicherplatz erfordert eine ressourcenschonende Programmierung 
und limitiert die Anzahl gleichzeitig ausführbarer Aufgaben. Die serielle Kommu- 
nikation mit anderen Geräten kann u.a. über ein SPI-Interface erfolgen. Der Micro- 
controller wird mit 3,3 V betrieben und kann deshalb die gleiche Spannungsquelle 
wie der Beschleunigungssensor nutzen. [25] 

Zum Versenden von Daten über WLAN verbraucht das Transceivermodul bei 3 V 
Versorgungsspannung laut Datenblatt [25] zwischen 120 und 170 mA, beim Emp- 
fangen etwa 50 mA. Werden andere Aufgaben erledigt, bei denen das WLAN-Modul 
nicht benötigt wird, liegt die Stromaufnahme im Durchschnitt bei 80 mA. Um ener- 
giearme Einsatzszenarien zu ermöglichen, kann der Microcontroller zwischen zwei 
Arbeitszyklen in verschiedene Stand-by-Zustände versetzt werden, welche als sog. 
Schlafzustände (engl. Sleep-Mode) bezeichnet werden. Im Modem-Sleep-Modus 
verbraucht das Transceivermodul 15 mA. Das WLAN-Modul wird abgeschaltet. 
Der Prozessor arbeitet aber weiter, sodass eine kabelgebundene Datenübertragung 
möglich ist. Im Light-Sleep-Modus kann ein Verbrauch von 0,9 mA erreicht wer- 
den, da der Prozessor in einen Stromsparmodus versetzt wird. Um in einen Arbeits- 
zustand zurückzukehren, werden 3 ms benötigt. Eine dritte Möglichkeit stellt der 
Deep-Sleep-Modus dar, bei dem bis auf die interne Uhr alle Funktionen ausgeschal- 
tet sind. Es wird mit einem Verbrauch von 20 pA ein energiearmer Zustand erreicht. 
Zwischen 0,3 und 1s werden benötigt, um nach einer vorher festgelegten Zeitspanne 
wieder einen Arbeitsmodus einzunehmen. [25] [27] 

Zum vereinfachten Einsatz wurde ein Entwicklerboard von NodeMCU verwen- 
det. Dieses ermöglicht es, durch einen integrierten Spannungswandler das Modul 
über eine USB-Schnittstelle zu betreiben, welche eine Spannung von 5 V liefert und 
über die die Programmierung des Moduls erfolgen kann. Abbildung 8 zeigt das ver- 
wendete NodeMCU-Entwicklerboard, welches Abmessungen von (4,2 x 3 x 1,3) cm 
aufweist. 
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Abb. 8 NodeMCU-Entwicklerboard mit ESP8266 [75] 


Für die Entwicklung des Programms, welches auf dem Microcontroller ausgeführt 
wird, können unterschiedliche Programmiersprachen verwendet werden. Dabei 
wird grundsätzlich in Compiler- und Interpretersprachen unterschieden. Der 
Unterschied zwischen den beiden Ansätzen besteht darin, wie und wann die les- 
baren Programmierbefehle in für den Prozessor verständliche Maschinenbefehle 
umgesetzt werden. Bei Compilersprachen wird durch einen Compiler im Voraus 
der Programmausführung einmalig das eigentliche Programm erstellt, dessen 
Anweisung direkt vom Prozessor ausgeführt werden. Interpretersprachen führen 
mit einem Interpreter eine Zwischenschicht zwischen Programmiersprache und 
Prozessor ein. Der Interpreter stellt eine Software-Bibliothek dar, welche zur Lauf- 
zeit des Programmes den ausführbaren Maschinencode generiert. Kompilierte Pro- 
gramme werden schneller ausgeführt. Im Gegenzug ist die Programmentwicklung 
bei Interpretersprachen einfacher, da die Programme sofort getestet werden kön- 
nen, was die Fehlersuche erleichtert. [18] 

Verwendet wurde bei dem vorliegenden Sensorkonzept die Interpretersprache 
LUA. Für LUA sind Module bspw. für das Aufbauen einerWLAN- und SPI-Verbindung, 
sowie für einige Übertragungsprotokolle wie HTTP und MQTT vorhanden, welche 
eine objektorientierte Programmierung ermöglichen. Nach Erstellung eines finalen 
Messprogramms lässt sich dieses auch als kompiliertes Programm auf den Micro- 
controller spielen. 

An das Transceivermodul werden die folgenden Anforderungen gestellt: Es soll 
erstens mit dem Beschleunigungssensor über eine SPI-Verbindung kommunizie- 
ren und den Ablauf einer Messung steuern. Zweitens sollen die Messwerte über ein 
WLAN drahtlos versendet werden. Zudem soll das Modul sich in der Zeit zwischen 
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den Messzyklen in einen energiearmen Zustand versetzen lassen. Der Microcontrol- 
ler ESP8266 erfüllt mit dem SPI-Interface, dem WLAN-Modul und der Möglichkeit 
einen energieeffizienten Sleep-Modus einzunehmen diese Anforderungen. 


Energieversorgung 

Die Energieversorgung des Sensorknotens wird durch einen Lithium-Polymer- 
Akkumulator mit 2500 mAh Kapazität realisiert. Ein Aufladen mittels Ladegerät 
oder ein Austausch des Akkus ist im laufenden Fahrbetrieb oder bei schwer zugäng- 
licher Einbaulage des Sensorknotens nur mit Aufwand möglich. Es wird deshalb ein 
Energiewandler (engl. Energy Harvester) zum Aufladen des Akkumulators einge- 
setzt, welcher ungenutzte Energie aus der Umgebung „erntet“ und diese in nutzbare 
Energie umwandelt. Je nach Umgebungsbedingungen können verschiedene Ener- 
giequellen wie Wärme, Licht oder Vibration genutzt werden. 

Die Wandlung von Wärme in elektrische Energie basiert auf dem Seebeck- 
Effekt, welcher ein elektrisches Potential in einem Leiter aufgrund von Temperatur- 
gradienten beschreibt. Wie groß dieses Potential ist, hängt vom Material des Leiters 
ab und wird durch den Seebeck-Koeffizienten beschrieben. Werden zwei Werkstoffe 
mit unterschiedlichen Seebeck-Koeffizienten eingesetzt, entsteht eine Potentialdif- 
ferenz zwischen den beiden Materialien. Die erzeugte Spannung beträgt wenige mV. 
Deshalb werden bei solchen Wandlern viele Thermopaare aus n- und p-dotierten 
Halbleiterbeinen zusammengeschaltet, womit Spannungen im Bereich einiger hun- 
dert mV erzeugt werden können. Für Mikrowandler liegt die Leistung bei einer Tem- 
peraturdifferenz von 10 K zwischen 0,1 und 2 mW. [8] [67] 

Eine weitere Möglichkeit ist die Wandlung von Licht mittels Solarzellen in 
elektrische Energie, was z.B. zur Stromerzeugung kommerziell eingesetzt wird. 
Im Jahr 2017 wurde 6,1 % des in Deutschland erzeugten Stroms durch Photovol- 
taik gewonnen. [64] Ein miniaturisierter Einsatz erfolgt in Taschenrechnern schon 
seit den 1980er-Jahren und ist auch zur Versorgung eines Funksensorknotens mög- 
lich. Die tatsächlich verfügbare Energie lässt sich allerdings nur grob abschätzen, 
da diese erheblich von der räumlichen Orientierung der Zelle, des Lichtspektrums 
und der verfügbaren Lichtintensitäten abhängt. Im Außenbereich beträgt über das 
Jahr gemittelt die verfügbare Leistung einige mW je cm? Fläche der Zelle. Im Innen- 
bereich ist die maximal verfügbare Lichtintensität deutlich geringer, dafür ist die 
Lichtintensität weitgehend konstant, sodass sich eine verfügbare Leistung von etwa 
15 uW je cm? ergibt. [67] 

Eine Wandlung von kinetischer Energie, die z.B. in der Umgebung in Form von 
Vibrationen enthalten ist, in elektrische Energie ist ebenfalls möglich. Die kinetische 
Energie aus der Umgebung wird auf eine Masse übertragen. Durch die Relativbewe- 
gung dieser Masse bezüglich eines Trägersystems kann unter Ausnutzung des indukti- 
ven, kapazitiven oder piezoelektrischen Effekts eine elektrische Leistung zur Verfügung 
gestellt werden, welche maximal ist, wenn die Systeme in Eigenfrequenz schwingen. 
Die meisten Systeme besitzen eine, aufwendigere Systeme mehrere oder einstellbare 
Eigenfrequenzen, da sich schon bei recht geringen Abweichungen der Anregungsfre- 
quenz von der Eigenfrequenz die Leistungsausbeute erheblich verringert. [67] [14] 
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Wird ein piezoelektrischer Werkstoff einer Krafteinwirkung wie Zug oder Druck 
ausgesetzt, verschieben sich die Schwerpunkte der positiven und der negativen 
Ladungen im Kristallgitter. Die dadurch erfolgte Veränderung der elektrischen Pola- 
risation sorgt für das Entstehen einer elektrischen Spannung. Die dabei erzeugte 
elektrische Ladung ist proportional zur mechanischen Spannung, also damit pro- 
portional zur anliegenden Beanspruchung. Als piezoelektrischer Werkstoff werden 
zumeist polykristalline ferroelektrische Keramiken wie z.B. Blei-Zirkonat-Titanat 
(PZT) oder polymeres Polyvinylidenflourid (PVDF) verwendet. Bei solchen Vibra- 
tions-Wandlern kommt oft ein mit einem piezoelektrischen Material beschichteter 
Biegebalken zum Einsatz, welcher auf einer Seite eingespannt ist. Die freie Seite 
wird in Schwingung versetzt, wodurch Dehnungen und Stauchungen in dem Mate- 
rial auftreten und eine Ladungsverschiebung verursachen. Die Eigenfrequenz des 
Harvesters muss zu der Erregerfrequenz des Anwendungsfalls passend ausgelegt 
sein. Je nach Größe des auf dem Biegebalken aufgebrachten piezoelektrischen 
Materials und der Auslenkung können dann Leistungen im Bereich von 0,5 bis 
1mW erreicht werden. Ein solches System mit einer Schwungmasse am freien Ende 
zum Erhöhen der einwirkenden Kraft ist in Abbildung 9 dargestellt. [40] [29] [61] 


Masse 


Piezoelektrische Schicht 


Träger / Gehäuse 
Abb. 9 prinzipieller Aufbau eines Biegebalkens mit piezoelektrischem Material [67] 


Bei dem vorliegenden Sensorkonzept wurde ein piezoelektrischer Vibrations- 
Harvester in Form eines Biegebalkens mit Piezofolie ausgewahlt. Die Verwendung 
von Solarzellen scheidet aufgrund der schlechten Lichtverhältnisse und des Ver- 
schmutzungsgrades am Anbringungsort des Sensorknotens unter einer Straßen- 
bahn aus. Bei der Nutzung eines Thermowandlers besteht vor allem im wärmeren 
Teil des Jahres das Problem, dass die Temperaturdifferenzen für eine ausreichende 
Energieversorgung nicht groß genug sind. 


3.2 Netzwerkkommunikation mit HTTP 


Die im Sensorknoten gewonnenen Messdaten sollen über das WLAN versendet wer- 
den. Damit eine Datenübertragung zwischen zwei Endgeräten stattfinden kann, 
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werden Protokolle benötigt, nach denen die Kommunikation erfolgt. Anwendungs- 
protokolle sind eine Sammlung standardisierter Regeln. Sie steuern die Verbindung 
sowie den Ablauf des Datenaustauschs zwischen zwei Endgeräten. [20] 

Als ein solches Anwendungsprotokoll wurde im bestehenden Sensorkonzept 
HTTP (Hypertext Transfer Protocol) verwendet. Der Austausch von Daten basiert 
bei diesem Protokoll auf einer Client-Server-Logik, was bedeutet, dass der Aufbau 
der Kommunikation nur in einer Richtung möglich ist. Der Server nimmt Anfragen 
entgegen und beantwortet diese. [77] 

Abbildung 10 zeigt den Ablauf einer Datenübertragung mittels HTTP. Clients 
sind Anwendungen, welche mit dem Server kommunizieren. Im vorliegenden Kon- 
zept stellen der Sensorknoten und die Leitwarte Clients dar. Zunächst fragt der Cli- 
ent über eine URL (z.B. http://localhost/php/FWRITE_3.php) oder die IP-Adresse 
(z.B. 10.10.0.1) des Servers eine Verbindung an. Diese wird entweder negiert oder 
bestätigt. Wenn die Verbindung bestätigt wurde, sendet der Client eine Anfrage 
(engl. Request) an den Server. Diese besteht aus einem Nachrichtenkopf, einem sog. 
Header, an welchen als Nachrichtenrumpf Daten angefügt werden. 


Clients Server 
Verbindungsaufbau via URL 
www.example.com 


Verbindungsbestatigung 


| f APACHE e 
Sensorknoten http-Anfrage J 


Header- und Datentransfer 


Empfangsbestatigung/ Serverantwort 


> mit Headerinformation 


Schließen der Verbindung 


Leitwarte 


Abb. 10 Verbindungsablauf HTTP 


Die konkrete Request-Nachricht des Sensorknotens an den Webserver ist in Abbil- 
dung 11 dargestellt, welche mit Ausnahme der letzten Zeile ausschließlich aus dem 
Header besteht. Auf den Header folgen die zu übertragenden Daten. Die erste Zeile 
enthält die Anfragemethode und die URL des Servers. Hier erfolgt eine Übermitt- 
lung an das auf dem Server freigegebene PHP-Skript zur weiteren Datenbehandlung. 
Der Header beinhaltet weiterhin Informationen wie die verwendete HTTP-Version, 
die IP-Adresse des Servers, ob die Verbindung anschließend geöffnet bleibt oder 
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Header 


ng.len(data).. 


data, ion(conn, pay 1) end) 
Abb. 11 HTTP-Anfrage des Sensorknotens an den Webserver 


geschlossen werden soll, sowie Angaben über das Format und die Länge der mit der 
letzten Zeile der Anfrage angebundenen Daten. 

Schon ohne Daten müssen aufgrund des Headers je Nachricht etwa 200 Zei- 
chen versendet werden. Ein Zeichen belegt dabei zwischen einem und vier Byte. 
Wird vereinfacht eine durchschnittliche Zeichengröße von 2,5 Byte angenommen, 
ergibt sich eine Headergröße von 500 Byte. Die maximal zulässige Länge einer 
Request-Nachricht liegt mit Verwendung eines Apache-Webservers bei 16 kByte. [26] 
Durch den Header wird bereits ohne angehangene Messinformationen eine Nach- 
richt von etwa 3% der maximal zulässigen Größe übertragen. Eine Zeichenkette in 
LUA besitzt eine maximale Länge von 2 kByte. Eine Nachricht wird als Zeichenkette 
aus dem Header und den zu übertragenden Daten zusammengesetzt, wobei der 
Header 25 % der zulässigen Nachrichtengröße verursacht. 

Der Server antwortet mit einer Response-Nachricht, die aus Headerinformationen 
und falls mittels Request angefordert aus einem Dokument besteht. Abbildung 12 zeigt 
ein Beispiel eines Response-Headers. Dieser enthält z.B. Informationen wie einen Sta- 
tuscode und den Zeitpunkt der Antwort. Sollen weitere Daten gesendet werden, muss 
eine erneute Anfrage des Clients nach dem beschriebenen Schema erfolgen. 


HTTP/1.x 208 OK 

Date: Tue, 98 Sep 2089 15:47:06 GMT 
Server: Apache/1.3.34 Ben-SSL/1.55 
Keep-Alive: timeout=2, max=200 
Connection: Keep-Alive 
Transfer-Encoding: chunked 
Content-Type: text/html 


Abb. 12 Beispiel eines Response-Headers [19] 


Soll die Verbindung nach der erfolgten Antwort des Servers geöffnet bleiben, um 
weitere Daten ohne erneuten Verbindungsaufbau zu übertragen, muss dies mit der 
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Request-Nachricht vom Client angefordert werden. In Abbildung 11 erfolgt das mit 
dem Ausdruck „Connection: keep-alive“ in der vierten Zeile. Es ist abhängig vom 
Webserver und dessen Konfiguration, ob und für wie viele Anfragen in welchen 
Zeitabständen die Verbindung erhalten bleibt. Diese Informationen sind Teil des 
Response-Headers. Im Beispiel von Abbildung 12 zeigt die vierte Zeile, dass die Ver- 
bindung beendet wird, wenn zwischen den Requests mehr als 2 s liegen oder mehr 
als 200 Anfragen den Webserver erreicht haben. Mit dem darauffolgenden „keep- 
alive“ wird bestätigt, dass die Verbindung geöffnet bleibt. [59] 

Die maximal mögliche Anzahl an Request-Nachrichten, welche innerhalb einer 
Verbindung gesendet werden können, wird durch die verfügbaren Ressourcen des 
Webservers bestimmt. Für das Aufrechterhalten der Verbindung wird Arbeitsspei- 
cher beansprucht. Werden nur weitere Verbindungen geöffnet ohne alte zu schlie- 
ßen, wird der Webserver deshalb nach einer gewissen Zeit überlastet sein. Des- 
halb ist es notwendig, die Anzahl der möglichen Anfragen oder die Zeitabstände 
zwischen einzelnen Requests zu limitieren und die Verbindung anschließend zu 
schließen. [44] 

Das verwendete HTTP-Protokoll gilt als ein sehr zuverlässiges und sicheres Pro- 
tokoll. Die Daten werden nur zu einem definierten Ziel übertragen und es erfolgt 
eine Rückmeldung, ob diese dort auch angekommen oder ob sie korrumpiert wor- 
den sind. Aufgrund des großen Datenheaders, des Zeitverzugs durch die vielen Zwi- 
schenschritte und des Schließens der Verbindung nach einer gewissen Zeitdauer 
oder Anzahl an Requests können keine Echtzeitübertragungen oder Datenstreams 
realisiert werden. Es ist mit HTTP demzufolge nur sinnvoll, größere Datenmengen 
in Paketen anstatt einzelner Werte zu senden. Eine Kommunikation findet nur zwi- 
schen genau einem Client und genau einem Server statt. Es ist nicht möglich, dass 
die gleiche Nachricht an viele Empfänger gleichzeitig versendet wird. [53] 


3.3 Beschreibung des messtechnischen Basiskonzepts 


In diesem Kapitel erfolgt eine Beschreibung der Rahmenbedingungen der Messun- 
gen. Anschließend wird das Zusammenwirken der Komponenten im Gesamtablauf 
einer Messung dargestellt. 

Mit dem bestehenden Sensorsystem sollen Ermüdungs- und Verschleißprozesse 
von Straßenbahn-Komponenten wie z.B. Wälzlagern erkannt werden. Schwingungs- 
parameter eignen sich gut als zustandsbeschreibende Merkmale von Komponen- 
ten wie Wälzlagern hinsichtlich Verschleiß und Ermüdung. Es erfolgt eine Messung 
der Schwingbeschleunigung des Körperschalls an den Gehäusen von Getriebe und 
Radlager einer Antriebseinheit der Straßenbahn. Als weitere Parameter werden 
Schwinggeschwindigkeit und Schwingweg benötigt, die sich durch Integration der 
Schwingbeschleunigung berechnen lassen. [78] Diese Schwingungsparameter eig- 
nen sich zur Zustandsbeschreibung, da aufgrund von Form- und Lageabweichun- 
gen, der Oberflächenbeschaffenheit, infolge von Unwuchten und den Betriebsbe- 
dingungen der Elemente eines technischen Systems mechanische Schwingungen 
entstehen. Diese erzeugen Schallwellen, welche sich u.a. als Körperschall auf die 
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Gehäuse der Komponenten ausbreiten. Schädigungen bewirken Veränderungen des 
Schallfeldes einer Komponente und sind somit über eine geeignete Auswertung der 
zustandsbeschreibenden Parameter erkennbar. Teilweise befinden sich die Schädi- 
gungen auch im hörbaren Bereich. So deuten bspw. laute metallische Geräusche auf 
fehlenden Schmierstoff oder zu hohe Belastung hin. [10] [74] 

Verschleiß- und Ermüdungsvorgänge finden bei Wälzlagern sehr langsam und 
über einen langen Zeitraum statt, sodass für eine Zustandsüberwachung nicht 
ununterbrochen gemessen werden muss. Vielmehr ist eine Vergleichbarkeit der 
gemessenen Daten relevant, auf die eine Vielzahl von Einflussgrößen wirken, wie 
z.B. Umweltbedingungen in Form von Feuchte und Temperaturschwankungen, die 
Verkehrslage, das Überfahren beschädigter Gleise sowie ein generell instationäres 
Betriebsverhalten mit vielen Beschleunigungs- und Bremsvorgängen. [78] 

Im Vorfeld wurde ein geeigneter Gleisabschnitt identifiziert, welcher die Anfor- 
derungen bezüglich einer reduzierten Anzahl an Einflussgrößen erfüllt. Eine Ver- 
gleichbarkeit der Messwerte wird hergestellt, indem eine Messung immer am glei- 
chen Abschnitt durchgeführt wird. Zur Positionsbestimmung wird der Raspberry Pi 
mit einem GPS-Modul ausgestattet. Der RPI fragtlaufend die Position ab und spannt 
das WLAN auf, wenn der zuvor definierte Gleisabschnitt erreicht wird. 

Abbildung 13 zeigt, wie eine Messaufnahme ausgelöst wird. Der Sensorknoten 
wacht nach einer Minute für wenige Sekunden auf und sucht das WLAN. Dieser Vor- 
gang wird im weiteren Verlauf der Arbeit als Grundzustand bezeichnet. Verläuft die 
Suche erfolglos, wird wieder der Sleep-Modus eingenommen. Ist der Aufbau einer 
WLAN-Verbindung erfolgt, kommuniziert das Transceivermodul mit dem Sensor 


Messen 
Messdaten versenden 


Abb. 13 Ablauf Messwertaufnahme mittels des Sensorknotens 


Sleep-Modus 


Beschreibung des messtechnischen Basiskonzepts 23 


über das SPI-Interface, weckt diesen aus dem Sleep-Modus auf und löst eine Mes- 
sung aus. Der Beschleunigungssensor nimmt 3072 Werte auf und speichert diese im 
Capture-Buffer zwischen. Anschließend folgt der Sendevorgang, bei dem die Mess- 
werte in Paketen mit je 128 Werten vom Microcontroller aus dem Capture-Buffer des 
Sensors ausgelesen und anschließend über das WLAN versendet werden. Sind alle 
Werte erfolgreich versendet wurden, werden Transceivermodul und Sensor wieder 
in den Sleep-Modus versetzt. In Abschnitt 3.4 werden die eben genannten Betriebs- 
zustände tabellarisch mit den laut Datenblättern zu erwartenden Stromverbräuchen 
erfasst. Zudem erfolgt eine grafische Darstellung des zu erwartenden Lastprofils. 

Über das vom Raspberry Pi aufgespannte WLAN können die in Abbildung 14 
dargestellten Komponenten Sensorknoten, Webserver und Leitwarte miteinander 
kommunizieren. Das Transceivermodul des Sensorknotens sendet die Messdaten an 
den Webserver, welcher sich auf dem RPI befindet. Auf diesem wird ein PHP-Skript 
aufgerufen, welches die Daten entgegennimmt, das Datenpaket in Einzelwerte 
trennt, Metainformationen wie bspw. die aktuelle Zeit hinzufügt und die Messwerte 
in einer CSV-Datei abspeichert. Der Webserver sendet mit einer Response-Nachricht 
die Bestätigung der Anfrage an den Sensorknoten zurück. Die Leitwarte schickt ein 
Request und erhält an die Antwort des Webservers als Nachrichtenrumpf angebun- 
den die Datei mit den Messdaten, welche anschließend durch die Leitwarte verar- 
beitet, visualisiert und bewertet werden. 


Datenbehandlung Datenablage CSV-Datei 
u 


Personal Home Page 


asesjqeuajeq 


Bildquelle: 
https://amazon.de 


JOAIISQIM UOA 


Datenübertragung 
an Webserver 


Raspberry Pi 
“i Client 
( YELETTETETET | o 
, (((e ))) 
"| A 
Sensorknoten WLAN 


z.B. an TRAM Leitwarte / Analyse 


Abb. 14 Datenübertragung im bestehenden Sensorsystem [58] 


Raspberry Pi und Leitwarte können so weit vom Sensorknoten entfernt sein, wie 
das WLAN mit einer Reichweite von etwa 70 m reicht. Im vorliegendem Kon- 
zept können deshalb mehrere Sensorknoten an multiplen Stellen unter der Bahn 
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gleichzeitig im Einsatz sein. Das Messkonzept mit großen Pausen zwischen den 
Messaufnahmen schafft in Kombination mit den möglichen Sleep-Modi der ver- 
wendeten Hardware die Grundlage für energiearme Zustände. Diese ermöglichen 
eine kabellose Stromversorgung des Sensorknotens sowie eine lange energetische 
Lebensdauer der eingesetzten Energieversorgung, welche aus einem mit Umge- 
bungsenergie gespeisten Akku besteht. Der RPI und die Leitwarte befinden sich im 
Fahrgastraum der Straßenbahn, weshalb eine kabelgebundene Stromversorgung 
problemlos möglich ist. 


3.4 Gesamtenergiebilanz des Sensorknotens und 
Optimierungspotentiale 


In Abhängigkeit von den jeweiligen Betriebszuständen des Sensorknotens werden 
laut den Datenblättern [4] und [25] Verbräuche in den Größenordnungen der in der 
folgenden Tabelle 1 dargestellten Werte erwartet. 


Tab.1 Stromverbrauch Transceivermodul und Beschleunigungssensor 


Zustand Transceivermodul Beschleunigungssensor Summe 
(bei 3V) (bei 3,3V) 

Grundzustand 80 mA 80 mA 

Messen 80 mA 43 mA 123 mA 

Sendebetrieb 120-170 mA 43 mA 163 - 213 mA 

Sleep-Modus 20 uA 230 uA 250 uA 


Im Rahmen des Traincon-Projektes wurde ein Simulationsmodell des Sensorkno- 
tens auf Basis von Datenblattwerten entwickelt. Abbildung 15 stellt das Lastprofil 
des simulierten Sensorknotens dar. Im unteren Diagramm ist zu erkennen, dass 
eine stündliche Messung simuliert wurde. Bei dieser findet kurzfristig eine Leis- 
tungsaufnahme von 580 mW statt. Das obere Diagramm zeigt den Leistungsbedarf 
des Sensorknotens bei einem Messzyklus im Detail. Nach dem Aufwachen befindet 
sich das Transceivermodul im Grundzustand. In diesem baut es innerhalb von etwa 
5 seine Verbindung zum WLAN-Netzwerk auf. Beim anschließenden Messvorgang 
werden die 3072 Messwerte im Capture-Buffer des Sensors zwischengespeichert. Im 
vorliegendem Messkonzept wird das Beschleunigungssignal mit 4,56 kHz abgetas- 
tet, sodass die 3072 Werte innerhalb von etwa 0,7 s aufgenommen werden. Diese 
Messwerte werden im Sendebetrieb ausgelesen und an den Webserver versendet. 
Durch eine Evaluierung der Simulation durch Messungen am realen Sensorknoten 
wurde eine Sendedauer von 15 s ermittelt. [34] 
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Leistungsaufnahme in [W] 
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Abb. 15 simuliertes Lastprofil Sensorknoten 


Für einen Betrachtungszeitraum von einem Tag mit stündlichen Messungen ergeben 
sich fiir den simulierten Sensorknoten die im Sankey-Diagramm in Abbildung 16 
dargestellten Energiefliisse. Der Vibrations-Harvester kann den abfallenden 
Ladungszustand des Akkus nicht vollstandig ausgleichen. Der Sensorknoten kann 


Lade/Entlade- 
Verluste 0.5 [%] 


Transceiver 1.5 [%] 


Sensor 0.0 [%] 


Batterie 99.0 [%] 
33300.0 [Ws/Tag] 

(Anfangsladung 

2500 [mAh] ) 


Batterie 98.0 [%] 
32943 [Ws/Tag] 


Vibrations-Harvester 1.0 [%] 
322.5 [Ws/Tag] 


Abb. 16 Sankey-Diagramm mit Energieflüssen des bestehenden Sensorkonzepts [34] 
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Abb. 17 Lastprofil mit verringerter Sendedauer 


so etwa weitere 100 Tage betrieben werden. Um den Sensorknoten mit einer Akku- 
ladung länger versorgen zu können, könnte der Abstand zwischen zwei Messungen 
z.B. auf 1,5 Stunden vergrößert werden. [34] 

Abbildung 16 zeigt, dass das Transceivermodul den größten Anteil am Energie- 
verbrauch besitzt. Wird ein Modul mit einer geringeren Leistungsaufnahme ver- 
wendet, kann der Sensorknoten länger betrieben werden. 

Ein weiterer Ansatzpunkt besteht in der Verringerung der Dauer des Sendevor- 
gangs. Gelingt es, die Sendedauer wie in Abbildung 17 dargestellt zu reduzieren, 
befindet sich das Transceivermodul für längere Zeit im energiesparenden Sleep-Mo- 
dus und die Energieaufnahme sinkt. Eine Möglichkeit wird im Ersetzen des Kom- 
munikationsprotokolls HTTP durch ein leichtgewichtiges Protokoll mit weniger 
Kommunikationsschritten gesehen. 

Optimierungsansätze zu den beiden oben genannten Punkten werden in 
Kapitel 4 aufgezeigt, die Umsetzung eines Ansatzes durch Verwendung des Proto- 
kolls MQTT zur Datenübertragung in Kapitel 5 beschrieben. Dessen Wirksamkeit 
wird in Kapitel 6 untersucht. Dabei wird ein Messszenario entwickelt, welches eine 
vergleichende Einschätzung des bisherigen und des optimierten Konzeptes auf 
Basis realer Werte ermöglicht. 


4 Darstellung und Bewertung von 
IT-Konzepten zur Verbesserung der 
Energieeffizienz 


Schon bei der Entwicklung des bestehenden Sensorkonzepts wurden Möglichkeiten 
zur Verbesserung der Energieeffizienz durch Änderungen im IT-Konzept der Daten- 
übertragung gesehen. In diesem Kapitel werden einige alternative Möglichkeiten 
zur Datenübermittlung aufgezeigt. Prinzipiell können die Abläufe einer Datenüber- 
tragung und die damit verbundenen softwaretechnischen Anforderungen mit dem 
OSI-Referenzmodell (OSI - Open System Interconnection) beschrieben werden, 
welches im Folgenden vorgestellt wird. 


4.1 OSI-Schichtenmodell und Einordnung des 
bestehenden Sensorkonzepts 


Der Transport von Daten durch ein Netzwerk wird von Protokollen organisiert, wel- 
che verschiedene Funktionen zu erfüllen haben. Diese Abläufe können mittels des 
OSI-Referenzmodells beschrieben werden, welches einen modularen Aufbau mit 
unterschiedlichen Schichten beinhaltet. Jede Schicht besitzt eine besondere Fähig- 
keit, welche der Gesamtkommunikation als Dienstleistung zur Verfügung gestellt 
wird und wiederum von verschiedenen Protokollen erfüllt werden kann. Einige Pro- 
tokolle erstrecken sich über mehrere Schichten und erfüllen damit mehrere Aufga- 
ben. Abbildung 18 zeigt den Aufbau des OSI-Schichtenmodells. Die Kenntnis dieses 
Modells erleichtert das Verständnis und die Einordnung der in diesem Kapitel vor- 
gestellten Alternativkonzepte. [9] [20] 
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Abb. 18 OSI-Schichtenmodell nach [77] und [9] 
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Die unterste Schicht ist die Bitübertragungsschicht oder auch Physical Layer 
genannt. Sie wandelt die Bits in ein zum Übertragungsmedium passendes Signal 
um und ist damit die Schnittstelle zum Übertragungsmedium, welches selbst nicht 
Teil des Modells ist. Die Protokolle der ersten Schicht unterscheiden sich jedoch nur 
nach dem eingesetzten Übertragungsmedium und -verfahren. Die nächste Schicht, 
die Sicherungsschicht, enthält Funktionen zur Fehlererkennung und Fehlerbehe- 
bung und sorgt damit für eine zuverlässige und funktionierende Verbindung. Die 
dritte Schicht stellt die Vermittlungsschicht dar, in welcher die logische Adressie- 
rung der Endgeräte erfolgt, was eine Wegfindung der Daten vom Sender zum Emp- 
fänger ermöglicht. In der Transportschicht als vierte Schicht wird der Datenfluss 
organisiert, indem die Datenpakete einer Anwendung zugeordnet werden. Sie ist 
damit die Schnittstelle der transportorientierten Schichten 1 bis 4 mit den anwen- 
dungsorientierten Schichten 5 bis 7. [20] 

Die fünfte Schicht, die Kommunikationssteuerung, beinhaltet die Steuerung der 
Verbindung und des Datenaustausches. Da die Daten je nach Plattform verschie- 
den dargestellt werden, werden diese in der Darstellungsschicht als sechste Schicht 
in ein unabhängiges Format gebracht. Zudem erfolgt hier die Verschlüsselung und 
Kompression von Daten. In der Anwendungsschicht als siebte Schicht findet die 
Dateneingabe sowie -ausgabe statt. [20] [77] 

Im bestehenden Sensorsystem erfolgt die Datenübertragung über ein WLAN. 
Dieses besitzt in Gebäuden eine maximale Reichweite von etwa 40 bis 70 m und ver- 
wendet als Übertragungsmedium Radiowellen im Bereich von 2,4 oder 5 GHz. Die 
IEEE-Norm (IEEE - Institute of Electrical and Electronics Engineers) 802.11, durch 
welche die Normung von WLAN erfolgt, spezifiziert im OSI-Schichtenmodell die 
untersten beiden Schichten. Die Leistungsaufnahme des verwendeten Transceiver- 
moduls im Sendebetrieb beträgt 400 mW. Ein WLAN-Router kann mindestens 65.535 
IP-Adressen vergeben, sodass unter Vernachlässigung der realen Ressourcenbe- 
schränkung theoretisch mehr als 65.000 Geräte in einem WLAN miteinander kom- 
munizieren können. Damit Geräte auf der Sicherungsschicht explizit angesprochen 
werden und den höheren Schichten ihre Dienste bereitstellen können, besitzen sie 
eine eindeutige individuelle MAC-Adresse. [28] [15] [55] 

Das Netzwerk des bestehenden Konzepts arbeitet mit dem IP-Protokoll (IP - 
Internet Protocol) als Protokoll der Vermittlungsschicht. Mit diesem Protokoll 
bekommen die Geräte Netzwerkadressen zugeordnet, wodurch Datenpakte adres- 
siert und damit dem richtigen Ziel zugeordnet werden können. In der Transport- 
schicht wird das TCP-Protokoll (TCP - Transmission Control Program) eingesetzt, 
welches für eine gesicherte Übertragung der Daten in der richtigen Reihenfolge 
sorgt. Bevor Daten übermittelt werden können, muss zunächst die Verbindung 
hergestellt sein. Dafür muss eine Seite die Verbindung aktiv anfragen. Die andere 
Seite muss sich in einem Abhörstatus befinden, welche eine Verbindung erlaubt. 
Anschließend ist ein Datenstrom zwischen den Endpunkten der Verbindung in 
beide Richtungen möglich. Das TCP-Protokoll nimmt die Daten von den Anwen- 
dungen entgegen, teilt diese in Pakete auf, welche mit einem Header versehen 
werden und übergibt diese an das IP-Protokoll. Durch den Header entsteht ein 
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Verwaltungsanteil von mindestens 20 Byte je Datenpaket. Die Datenpakete werden 
beim Empfänger durch das TCP-Protokoll in die richtige Reihenfolge gebracht, die 
Daten wieder zu einem Datenstrom zusammengesetzt und der richtigen Anwen- 
dung übergeben, welche durch eine Port-Nummer erkannt wird. Das Verwenden 
des TCP-Protokolls wird von dem eingesetzten anwendungsorientierten Protokoll 
HTTP, welches in Kapitel 3.2 vorgestellt wird und die Aufgaben der Schichten 5 bis 7 
erfüllt, gefordert. [3] [76] [23] 

Die folgenden zwei Ansatzpunkte ermöglichen eine kommunikationstechni- 
sche Optimierung: Zum einen ist der Einsatz eines anderen Protokolls der anwen- 
dungsorientierten Schichten mit kleineren Nachrichtenheadern und weniger Kom- 
munikationsschritten anstatt HTTP möglich (s. Abschnitt 4.3), wodurch teilweise 
auch ein anderes Protokoll der Transportschicht eingesetzt wird. Je nach konkret 
verwendetem Protokoll kann hierbei die bestehende Hardware weiterverwendet 
werden. Eine Alternative stellt der in Kapitel 4.2 vorgestellte Ansatz dar, bei dem 
bereits in den transportorientierten Schichten angesetzt wird. 


4.2 Alternativen in den transportorientierten Schichten 


Bei dieser Herangehensweise werden alle Protokolle durch alternative Verfahren 
wie z.B. ZigBee, Z-Wave oder Bluetooth Low Energy (BLE) ersetzt. Der Nachteil die- 
ses Ansatzes ist es, dass bei einer Umsetzung das gesamte Sensorkonzept geändert 
werden muss und damit nicht nur neue Hardware beschafft werden, sondern auch 
eine Einarbeitung in die neuen Hardware-, Software- und Programmierumgebun- 
gen erfolgen muss. Diese Protokolle werden im Folgenden vorgestellt, aber aus 
den eben angeführten Gründen im weiteren Verlauf der Arbeit nicht weiter umge- 
setzt. Bei einer zukünftigen Neukonzeption eines anderen Messkonzepts kann eine 
erneute Betrachtung dieser Konzepte in Erwägung gezogen werden. 


ZigBee 

ZigBee ist ein Funkstandard, welcher für energieeffiziente Anwendungen mit gerin- 
ger Datenrate, wie der Fernsteuerung von Aktoren und Übertragung von Sensor- 
daten, entwickelt wurde. Er ist ein häufig angewendeter Standard in der Haus-, 
Gebäude- und Industrieautomation, sowie der Lichttechnik. [72] [28] 

Je nach Leistung und verwendeter Sendefrequenz des Funkmoduls und den 
Bedingungen der Umgebung besitzt ein ZigBee-Netzwerk eine Reichweite von 10 
bis 100 m. Die sich im Netzwerk befindenden Endgeräte verwalten dieses autark. 
ZigBee baut auf dem IEEE 802.15-4-Standard auf, welches die unteren beiden 
OSI-Schichten spezifiziert und Parameter wie Modulation und Kanalzugriff defi- 
niert. Als Übertragungsmedium wird in Europa das 868 MHZ- und das 2,4 GHz-Band 
verwendet, über welches 20 bzw. 250 kBit je Sekunde übertragen werden können. 
Ein Transceivermoduls von Texas Instruments (TI) verbraucht im Sendebetrieb 
etwa 50 mW. [66] [72] [28] 

Es werden durch ZigBee aufbauend auf dem IEEE-Standard drei Gerä- 
tetypen definiert: Der ZigBee Coordinator, welcher das Netzwerk mit einer 
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Identifikationsnummer eröffnet und verwaltet, sowie der ZigBee Router, welcher 
sich einem bestehenden Netzwerk anschließen und dessen Reichweite vergrößern 
kann. Der Coordinator und die Router bilden, wie in Abbildung 19 dargestellt, sog. 
Netzwerkknoten. ZigBee End Devices können als dritter Gerätetyp nur mit dem 
Coordinator oder einem Router, nicht aber direkt untereinander kommunizieren. 
ZigBee kann im Gegenzug mit minimalen Ressourcen auf diesen Geräten imple- 
mentiert werden. Die Datenübertragung über die Netzwerkknoten kann über ver- 
schiedene Strukturen, sog. Netzwerktopologien, erfolgen, welche in Abbildung 19 
dargestellt sind. Vermaschte Netzwerke (engl. mesh network) bieten dabei den 
Vorteil höherer Übertragungssicherheit, da bei Ausfall eines Netzwerkknotens 
durch die vorhandene Redundanz die Datenübertragung über einen anderen 
Weg dennoch möglich ist. Jeder Netzwerkknoten bekommt vom Coordinator eine 
16-Bit-Adresse zugewiesen, sodass theoretisch für jedes Netzwerk 65535 Teilneh- 
mer möglich sind, wobei dies durch die eingeschränkte Datenübertragungsrate 
nicht praktikabel scheint. [28] [43] 
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® ZigBee End Devices 
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Abb. 19 mögliche Netzwerktopologien [38] 


ZigBee ermöglicht das sog. Binding, mit dem mehrere funktional zueinander gehö- 
rige Geräte logisch zusammengebunden werden können. So schickt ein End Device 
nur ein Datenpaket an den Coordinator, welcher die Anfrage wiederum an meh- 
rere sich im Netzwerk befindende und vorher als logisch verknüpft definierte End 
Devices übermittelt. [28] 

In der neuesten Spezifikation ZigBee 3.0 basieren die Anwendungen auf 
einem standardisierten Profil, welches für definierte Nutzungsfälle wie Energie- 
versorgung, Gebäudeautomatisierung, Lichtsteuerung, Gesundheitswesen und 
Telekommunikation den Datenaustausch durch Bibliotheken mit hinterlegten 
Attributen, Parametern und Befehlen regelt. Geräte mit einem entsprechenden 
Anwendungsprofil greifen auf diese Bibliotheken zurück. Das Erstellen eines 
eigenen Profils istim Gegensatz zu früheren Spezifikationen nicht mehr möglich, 
dafür wird eine Kompatibilität zwischen allen ZigBee 3.0-spezifizierten Geräten 
sichergestellt. [72] 
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Z-Wave 

Z-Wave wurde als Standard für die Gebäudeautomatisierung entwickelt und ist in 
diesem Bereich besonders auf dem amerikanischen Markt verbreitet. Wie auch bei 
ZigBee liegt der Fokus darauf, eine möglichst energieeffiziente Datenübertragung 
zu ermöglichen, sodass Z-Wave mit einer Datenrate von 40 kBits je Sekunde ebenso 
ungeeignet zur Übertragung von Audio- und Videodateien ist. Zur Datenübertra- 
gung wird das 868 MHz-Frequenzband genutzt. Das Grundprinzip ist das selbe wie 
bei ZigBee. Z-Wave baut ebenfalls auf dem IEEE 802.15-4-Standard auf, welcher 
die unteren beiden Schichten im OSI-Referenzmodell definiert und verwendet als 
Netzwerk-Topologie ein vermaschtes Netz. Da das Protokoll im Vergleich zu Zig- 
Bee deutlich simpler aufgebaut ist, können maximal je Netzwerk nur 232 Geräte 
teilnehmen und eine Übertragung ist nur über 4 Netzwerkknoten hinweg mög- 
lich. Demgegenüber steht eine höhere Reichweite von 40 bis zu 200 m. Ein Z-Wave 
Transceivermodul von Sigma-Designs besitzt eine Leistungsaufnahme von etwa 
106 mW. [13] [12] [57] [28] 


Bluetooth Low-Energy 

Bluetooth Low Energy (BLE) ist ein Bluetooth basierter Standard und seit 2010 
Teil der Bluetooth 4.0 Spezifikation mit dem Ziel der besonders energieeffizienten 
Übertragung von Daten und Sprache. Geräte können entweder Daten über BLE 
oder über das klassische Bluetooth übertragen oder auch für beide Varianten ver- 
wendbar sein. Die meisten Sensoren sind nur BLE-fähig, wohingegen die heuti- 
gen, meist als Gegenstelle verwendeten Smartphones und Tablets beide Varianten 
unterstützen. [41] 

BLE nutzt ebenfalls wie ZigBee oder WLAN das 2,4 GHz-Frequenzband, welches 
in 79 Kanäle mit je 1 MHz Bandbreite unterteilt wird und erreicht eine Reichweite 
von 10 bis 40 m. Ein Transceivermoduls von Texas Instruments (TI) verbraucht im 
Sendebetrieb etwa 30 mW. [65] [3] [28] 

Die Geräte können verbindungslos Daten übertragen, wobei ein Gerät als Bro- 
adcaster Daten versendet und ein weiteres als Observer die Daten empfangen kann, 
ohne dass eine Verbindung zwischen beiden Geräten aufgebaut wird. Eine zweite 
Möglichkeit besteht in einer verbindungsorientierten Übertragung. Bei BLE können 
Geräte die Funktion eines Masters oder eines Slaves einnehmen. Der Master über- 
nimmt die Koordination des Netzes und stellt seine individuelle Stationsadresse, 
welche vergleichbar mit der MAC-Adresse von Geräten z.B. in WLAN-Netzwerken 
ist, zur Identifikation des Netzwerkes zur Verfügung. Zum Verbinden senden die 
Slaves auf bestimmten Kanälen Verbindungsanfragen. Diese Kanäle werden vom 
Master regelmäßig gescannt und ein Verbindungsaufbau kann erfolgen. Über diese 
Verbindung können dann anschließend Daten übertragen werden. [28] [3] [41] 

Der Datenkanal eines Masters kann von bis zu 7 aktiven Slaves gleichzeitig ver- 
wendet werden. Aktive Slaves bekommen eine Adresse zur Kommunikation zuge- 
ordnet. Zusätzlich können 256 Slaves im Ruhezustand verwaltet werden, welche 
aber nicht aktiv kommunizieren können. Sobald die Slaves keine Daten mehr über- 
tragen, wird die Verbindung inaktiv und die Geräte können einen stromsparenden 
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Sleep-Modus einnehmen. Die Datenübertragung wird mit einer Datenrate von etwa 
1 MBit je Sekunde ermöglicht, diese teilen sich aber alle aktiven Slaves. [42] [28] [3] 


4.3 Alternativen in den anwendungsorientierten 
Schichten 


Das im bestehenden Sensorkonzept eingesetzte HTTP als Protokoll der anwen- 
dungsorientierten Schichten besitzt einige Eigenschaften, weswegen es nicht das 
ideale Protokoll zur Übertragung von Sensordaten darstellt. Jede mit HTTP versen- 
dete Nachricht beinhaltet einen großen Header und nach einiger Zeit oder Anzahl 
übertragener Nachrichten wird die Verbindung aufgrund eines Timeouts geschlos- 
sen. Bei Einsatz eines anderen Sensors als Applikationsklasse, bei dem es möglich 
und sinnvoll ist, laufend Messwerte auszulesen, wäre zudem die mangelnde Echt- 
zeit- und Streamingfähigkeit ein weiterer Nachteil. 

Wenn aus den am Beginn dieses Kapitels aufgeführten Gründen die bestehende 
Hardware verwendet werden soll, bieten sich als alternative, anwendungsorien- 
tierte Protokolle anstatt dem bisher verwendeten HTTP die Protokolle CoAP (Cons- 
trained Application Protocol) und MQTT (Message Queue Telemetry Transport) an. 
Diese werden im Folgenden vorgestellt. Für beide Protokolle sind im Gegensatz zu 
anderen sich sonst ebenfalls für IoT-Anwendungen anbietenden Protokollen, wel- 
che z.B. kurz in [3] vorgestellt werden, Bibliotheken für die LUA-Programmierumge- 
bung vorhanden. [52] 


CoAP (Constrained Application Protocol) 

Das Ziel bei der Entwicklung von CoAP war es, ein leichtgewichtiges Protokoll 
zur energieeffizienten Integration von Sensoren und Aktoren in die bestehende 
Internet-Architektur zu erhalten. So kann CoAP über einen Proxy simpel mit 
HTTP interagieren und damit in klassische Internet-Anwendungen eingebunden 
werden. [3] [16] 

CoAP baut als Protokoll der anwendungsorientierten Schichten auf UDP (User 
Datagram Protocol) in der Transportschicht auf. In den im OSI-Referenzmodell dar- 
unterliegenden Schichten werden weiter die selben Protokolle wie bei Einsatz von 
HTTP verwendet. Im Gegensatz zu TCP, welches bisher als Protokoll der Transport- 
schicht eingesetzt wurde, werden mit UDP Daten verbindungslos, also ohne Aufbau 
einer Verbindung zwischen Sender und Empfänger, übertragen. Deshalb besteht für 
den Sender keine Möglichkeit über eine Rückmeldung in der Transportschicht fest- 
zustellen, ob die Nachrichten überhaupt und in der richtigen Reihenfolge angekom- 
men sind. Es wird eine asynchrone Datenübertragung ermöglicht, bei der Nach- 
richten priorisiert und unabhängig voneinander anstatt in einer festen Reihenfolge 
geschickt und bearbeitet werden können, sodass große Nachrichten oder solche 
mit einer langen Bearbeitungszeit nicht die darauffolgenden Anfragen blockieren. 
Ein weiterer Unterschied ist, dass das Senden von Nachrichten an einen, aber auch 
an mehrere Empfänger gleichzeitig, möglich ist. Zudem werden der eigentlichen 
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Nachricht im Header mit einer Länge von 8 Byte nur sehr wenige Informationen 
hinzugefügt und es gibt keine Mechanismen zur Fehlererkennung, wodurch eine 
sehr schnelle Übertragung ermöglicht wird. Die Fehlererkennung und -behandlung 
wird durch CoAP vorgenommen. [76] [77] 

Abbildung 20 zeigt den Ablauf einer Kommunikation mittels CoAP, welches ana- 
log zu HTTP eine Client/Server-Logik besitzt. Eine CoAP-Nachricht beinhaltet einen 
4 Byte großen Header. Ein Verbindungsaufbau wird nicht benötigt. Ein Client sen- 
det eine Anfrage, welche der Empfänger beantwortet. Der Token ermöglicht eine 
Zuordnung der Antwort zu der jeweiligen Anfrage. An die Anfrage und die Antwort 
können die zu übertragenden Daten angehangen werden, welche in diesem Beispiel 
einen Temperaturwert darstellen. 


N-Con [42] 
Get/Temperature 
Token: [0x13] 


N-Con [77] 
Get/Temperature 
Token: [0x13] 

Payload: „23° C“ 


Abb. 20 Beispiel einer CoAP-Kommunikation [63] 


Es sind zudem Anfragen möglich, welche eine ereignisgesteuerte Kommunikation 
auslösen. So kann bspw. ein Sensor nach einem solchen Request dauerhaft bei 
Änderungen der Messwerte oder nach bestimmten Zeitabständen eine Nachricht 
an den anfragenden Client senden. [63] 

Es existiert eine Bibliothek, welche eine Implementierung von CoAP in das 
bestehende auf dem Microcontroller ausgeführte LUA-Programm vereinfacht 
ermöglicht. In der Dokumentation dieses CoAP-Modules in [39] wird allerdings dar- 
auf hingewiesen, dass es sich dabei um ein sehr frühes Entwicklungsstadium han- 
delt, welches zudem nicht den vollen Funktionsumfang enthält. Wenn weiterhin 
LUA als Programmiersprache eingesetzt werden soll, erscheint eine Verwendung 
nicht sinnvoll, solange keine ausgereiften Module existieren. Ein Einsatz von CoAP 
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ohne entsprechende Module ist nur mit sehr stark erhöhtem Programmieraufwand 
möglich. Bei erfolgter Weiterentwicklung des CoAP-Moduls für LUA ist ein zukünfti- 
ger Einsatz aber zu überdenken. 


MOTT (Message Queue Telemetry Transport) 

MQTT wurde von IBM zur Überwachung von Ölpipelines entwickelt und ist seit 2010 
frei verfügbar. Es ermöglicht Nachrichten über unzuverlässige Netzwerke und mit 
Einsatz ressourcenbeschränkter Geräte zu übertragen. MQTT ist ein verbindungs- 
orientiertes Protokoll und baut auf TCP und IP als Protokolle der Transport- und 
Vermittlungsschicht auf. [53] [17] 

MOTT besitzt eine Publish/Subscribe-Architektur, bei der sich Sender und 
Empfänger mit einem zentralen Server, welcher Broker genannt wird, verbinden. 
Der Broker speichert keine Daten, sondern verwaltet nur die Kommunikation. Die 
Clients verbinden sich nie direkt untereinander, sondern immer mit dem Broker. 
Clients können entweder Nachrichten unter einem bestimmten Topic bereitstel- 
len (= Publisher, Sender) oder Nachrichten eines bestimmten Topics über eine Art 
Abonnement empfangen (= Subscriber, Empfänger). Ein Client kann auch gleichzei- 
tig Publisher und Subscriber sein. [56] 

Ein Topic stellt eine Art Betreff dar, unter welchem die Nachrichten vom Pub- 
lisher veröffentlicht werden. Der Subscriber gibt an, dass er Nachrichten mit einem 
bestimmten Topic empfangen möchte. Das Topic kann ein einzelner Begriff sein. 
Auch eine Zusammensetzung von Begriffen in einer hierarchischen Struktur ist 
möglich. Unter diesem Kommunikationskanal veröffentlicht dann der Publisher 
Daten, indem er diese unter Angabe des Topics an den Broker sendet. Dieser über- 
prüft, welche Empfänger dieses Topic abonniert haben und sendet die Nachricht an 
alle Subscriber weiter. Eine MQTT-Nachricht verursacht einen mindestens 2 Byte 
großen Header. [56] 

Abbildung 21 zeigt anhand eines Beispiels das Grundprinzip von MQTT. Ein 
Temperatursensor misst als Wert „21°C“ und veröffentlicht diesen als Publisher 
unter dem Topic „temperature“. Die Subscriber Laptop und Mobile Device haben im 
Voraus dem Broker mitgeteilt, dass sie Nachrichten mit dem Topic „temperature“ 
abonnieren möchten. Der Broker empfängt nun die Nachricht „21°C“ unter dem 
Topic „temperature“, prüft, welche Clients diese abonniert haben, und sendet diese 
anschließend an die entsprechenden Clients Laptop und Mobile Device. 

Der prinzipielle Ablauf einer Nachrichtenübertragung mittels MQTT ist in 
Abbildung 22 dargestellt. Der Client fragt zu Beginn beim Broker eine Verbindung 
an. Der Broker bestätigt diese entweder mit einer Nachricht oder negiert diese. 
Sobald die Verbindung bestätigt wurde, überträgt und/oder empfängt der Client 
solange Nachrichten, bis die Verbindung aktiv von einer der beiden Seiten geschlos- 
sen oder die WLAN-Übertragung unterbrochen wird. Es gibt kein Beenden der Ver- 
bindung durch einen Timeout wie bei HTTP. 

Es existiert eine Bibliothek, welche eine Implementierung von MQTT in das auf 
dem Microcontroller ausgeführte LUA-Programm vereinfacht ermöglicht. 
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Abb. 21 Grundprinzip MQTT [31] 
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Abb. 22 prinzipieller Verbindungsablauf mit MQTT 


4.4 Übersicht und Vergleich der vorgestellten Protokolle 


Eine Übersicht über charakteristische Vergleichsgrößen der in den Kapiteln 4.2 
und 4.3 vorgestellten Konzepte bietet die folgende Tabelle 2. Die Reichweite der 
Funkübertragung ist stark von den jeweils konkreten Umgebungsbedingungen 
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Tab.2 Übersicht über mögliche Protokolle 


Kriterien WLAN mit WLAN mit WLANmit ZigBee Z-Wave BLE 
HTTP CoAP MQTT 
Reichweite in 40 - 70 10-100 40-200 10-40 


Gebäuden in [m] 


max. Datenrate in 240 0,25 0,04 1 
[MBit/s] 
Leistungsaufnahme 400 50 106 30 


Transceivermodul im 
Sendebetrieb in [mW] 


max. Anzahl aktiver > 65535 65535 232 7 
Clients 


abhängig, sodass die dort aufgeführten Werte nur für eine grobe Einschätzung die- 
nen. BLE besitzt mit maximal 40 m eine geringere Reichweite als die anderen aufge- 
führten Standards, die eine maximale Reichweite von 70 bis 200 m aufweisen. 

Ein Vergleich zwischen den Protokollen ergibt, dass die Datenrate der auf WLAN 
aufbauenden Protokolle mit dem Faktor 250 bis 6000 sehr viel größer ist als die 
Datenrate der anderen Konzepte. Die geringen Datenraten vor allem von ZigBee und 
Z-Wave erlauben ausschließlich eine Daten- und keine Sprach- oder Bildübertragung. 

Im Gegenzug beträgt die Leistungsaufnahme eines WLAN-Transceivermoduls 
das etwa 10-fache gegenüber einem Zig-Bee- oder BLE- und das Vierfache gegen- 
über einem Z-Wave-Modul. Die erhöhte Datenrate ermöglicht aber vor allem bei 
größeren Datenmengen eine deutlich reduzierte Übertragungsdauer, sodass das 
Transceivermodul dann längere Zeit einen energiesparenden Sleep-Modus einneh- 
men kann. 

Große Unterschiede bestehen auch in der maximal möglichen Anzahl gleichzei- 
tig aktiver Clients. Bei BLE ist diese auf sieben Geräte limitiert. ZigBee und WLAN 
lassen theoretisch 65535 Geräte je Netzwerk zu. In der Praxis scheint diese Anzahl 
aufgrund der Ressourcenbeschrankung der Router und der Datenrate unrealistisch. 

Im Rahmen dieser Bachelorarbeit soll das bestehende Sensorkonzept unter Ver- 
wendung der vorhandenen Hardware kommunikationstechnisch optimiert werden. 
Für ZigBee, Z-Wave und BLE sind zwar Transceivermodule mit gegenüber WLAN 
deutlich verringerter Leistungsaufnahme vorhanden. Ein Einsatz kann aber nur mit 
neuer Hardware stattfinden und scheidet deshalb als Optimierungsmöglichkeit aus. 
Zudem sind die möglichen Datenübertragungsraten niedrig. Mit BLE lassen sich 
außerdem durch die begrenzte Anzahl aktiver Clients keine Netzwerke bilden. 

Eine Übersicht mit einigen Vergleichskriterien über die in Kapitel 3.2 sowie in 
4.3 vorgestellten anwendungsorientierten Protokolle zeigt Tabelle 3. Ein Einsatz die- 
ser Protokolle ist mit der bestehenden Hardware möglich. 
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Tab. 3 Übersicht der vorgestellten anwendungsorientierten Protokolle 


Kriterien HTTP CoAP MQTT 
verbindungs- verbindungs-los verbindungs- 
Transport ae ee 
orientiert orientiert 
Mindestgröße Header 20 Byte 8 Byte 20 Byte 


Mindestgröße Transportschicht (TCP) (UDP) (TCP) 


Nachricht 


Mindestgröße Header 


ca. 420 Byte 4 Byte 2 Byte 
Anwendungsschicht y y y 
Publish / 
Architekt: R t/R 
rchitektur equest / Response Subscribe 


Die Unterschiede im Energieverbrauch ergeben sich zwischen den anwendungso- 
rientierten Protokollen vor allem durch die Sendedauer. Diese wird hauptsächlich 
durch die Größe und Anzahl der zu übermittelnden Nachrichten bestimmt. Bei 
HTTP und MQTT als verbindungsorientierte Protokolle erfolgt zum Aufbau der Ver- 
bindung ein Nachrichtenaustausch. CoAP baut auf dem verbindungslosen UDP-Pro- 
tokoll in der Transportschicht auf, sodass ein Verbindungsaufbau entfällt. Die Ver- 
bindung von HTTP wird nach einer gewissen Anzahl an Nachrichten oder einer 
bestimmten Zeitdauer unterbrochen. Es muss dann ein erneuter Verbindungsauf- 
bau stattfinden. Bei MQTT bleibt die Verbindung dauerhaft bestehen. 

Die Unterschiede in der Nachrichtengröße ergeben sich durch die vom Pro- 
tokoll angehängten Informationen. HTTP verursacht im Gegensatz zu CoAP und 
MOTT mit einer Größe von etwa 420 Byte im bestehenden Sensorkonzept einen 
sehr großen Header. In dieser Angabe ist zur Vergleichbarkeit die URL des Ser- 
vers nicht enthalten, da bei CoAP und MQTT die Adresse bzw. das Topic nach dem 
Header angefügt und nicht in die Headergröße miteinbezogen werden. Zählt man 
die Headergrößen von Anwendungs- und Transportprotokoll zusammen, benötigt 
CoAP durch Verwenden von UDP in der Transportschicht mit mindestens 12 Byte 
die geringste Datenmenge. Zudem entfällt bei CoAP der Nachrichtenaustausch zum 
Verbindungsaufbau. Die von MQTT verursachte Datenmenge liegt mit 22 Byte in 
einer ähnlichen Größenordnung. 

Ein weiterer Unterschied besteht in der Architektur der Protokolle. HTTP und 
CoAP nutzen eine Request/Response-Logik. Ein Client richtet eine Anfrage an einen 
Server, welche anschließend beantwortet wird. MQTT arbeitet nach dem Publish/ 
Subscribe-Prinzip. Ein Client veröffentlicht Daten unter einem bestimmten Topic. 
Ein anderer Client kann dieses Topic abonnieren. Ein sog. Broker verwaltet den 
Informationsaustausch. 

Es sind keine Untersuchungen vorhanden, in denen HTTP, MQTT und CoAP 
unter gleichen Testbedingungen miteinander verglichen wurden. So erfolgt in 
[16] ein Vergleich von MQTT mit QoS-Level 0 und CoAP bezüglich Übertragungs- 
dauer und zu übertragener Datenmenge. Es werden unter Laborbedingungen 
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Informationen mit einer Größe von 2500 Bytes übertragen. Die Sendedauer von 
MOTT ist gegenüber CoAP 20 % geringer, die Datenmenge um 10 % höher. In die- 
sem Szenario wird von einer einmaligen Informationsübertragung ausgegangen, 
sodass der Verbindungsaufbau bei MQTT in der Sendedauer und Datenmenge ent- 
halten ist. Wird von einem einmaligen Verbindungsaufbau ausgegangen, nachdem 
eine Übertragung vieler Nachrichten stattfindet, sinkt die Sendedauer von MQTT 
auf etwa ein Drittel der Dauer von CoAP. Die zu übertragene Datenmenge ist dann 
gleich groß. Der Vorteil von CoAP liegt vor allem bei instabilen Verbindungen oder 
solchen, bei denen der Client nach einer erfolgreich gesendeten Nachricht wieder 
in den Sleep-Modus versetzt wird. 

In dem in [50] vorgestellten Testszenario wird ein Vergleich von HTTP und 
MQTT mit QoS-Level 1 bezüglich Energieverbrauch und Ubertragungsdauer vorge- 
nommen. Als Client dient ein Android-Smartphone und als Server ein Desktop-PC. 
Die Datenübertragung erfolgt über ein WLAN-Netzwerk. Es wurde die Übertra- 
gung von 1024 Nachrichten mit einer Größe von je 1 Byte untersucht, welche so 
schnell wie möglich übermittelt werden sollen. Zum Verbindungsaufbau benötigt 
HTTP 20% weniger Energie, da bei MQTT das Abonnieren des Testtopics enthalten 
ist. Wird kein Topic abonniert, liegt der Verbrauch in der gleichen Größenordnung. 
Zum Nachrichten-Erhalten benötigt MQTT gegenüber HTTP in diesem Szenario 
etwa ein Zwanzigstel der Zeit und ein Fünfzigstel der Energie sowie zum Nachrich- 
ten-Versenden etwa ein Viertel der Zeit und ein Sechstel der Energie. Es tritt somit 
nicht nur eine Verringerung der Sendedauer, sondern auch eine Reduzierung der 
Stromaufnahme ein. 

In [47] wird eine Vielzahl an bestehenden Untersuchungen qualitativ zusam- 
mengefasst. Es wird bestätigt, dass im Allgemeinen Nachrichtengröße, Energiever- 
brauch und Datenmenge einer HTTP-Übertragung deutlich über denen von MQTT 
liegen, welche wiederum leicht höhere Werte als bei Einsatz von CoAP aufweist. 


4.5 Auswahl des MQTT-Protokolls 


Die Vorteile des leichtgewichtigen MQTT-Protokolls bestehen gegenüber HTTP bei 
der Übertragung von Sensordaten in der Publish/Subscribe-Logik sowie des gerin- 
gen Protokolloverheads. Es wird eine Verringerung der Sendedauer erwartet, welche 
zur Senkung des Energieverbrauchs des Sensorknotens führt. Zudem bietet MQTT 
den großen Vorteil, dass die Verbindung nicht nach einer gewissen Anzahl übertra- 
gener Nachrichten oder einer bestimmten Zeitdauer unterbrochen wird, wodurch 
eine streaming- und echtzeitfähige Kommunikation ermöglicht wird. Es wird eine 
ereignisgesteuerte Kommunikation ermöglicht, bei der z.B. Sensoren ohne vorhe- 
rige Anfrage eines Servers bei Eintreten von bestimmten Ereignissen sofort ohne 
erneuten Verbindungsaufbau Daten übertragen können. Ein weiterer Vorteil von 
MOTT besteht in der einfachen Skalierbarkeit mit bis zu mehreren hunderttausend 
Clients je Broker. Für den Publisher ist es unerheblich, an wie viele Subscriber die 
Nachricht letztendlich versendet wird. Eine Limitierung erfolgt durch die Ressour- 
cen des Brokers und die Kapazität des Netzwerkes. 
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In dieser Bachelorarbeit wird deshalb ein alternatives Sensorkonzept erstellt, 
in dem HTTP durch MOTT als Protokoll der anwendungsorientierten Schichten 
ersetzt wird. 


Konfigurationsmöglichkeiten von MQTT 

MOTT baut auf TCP als Protokoll der Transportschicht auf, sodass bei einer stabilen 
Verbindung eine komplette Übertragung der Nachrichten garantiert ist. Da MQTT 
für den Einsatz von instabilen Verbindungen entwickelt wurde, ist das Veröffent- 
lichen von Nachrichten in drei verschiedenen Servicequalitäten (QoS - Quality of 
Service) möglich. [56] 

Den Ablauf einer Nachrichtenübertragung der verschiedenen QoS zeigt 
Abbildung 23. Bei 00S 0 wird die Nachricht genau einmal gesendet. Der Sender 
erwartet keine Bestätigung und bekommt damit keine Rückmeldung, ob die Nach- 
richt angekommen ist. Diese Vorgehensweise wird auch „fire and forget“ genannt. 
Mit QoS 1 wird garantiert, dass die Nachricht mindestens einmal ankommt. Ein 
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Abb. 23 Ablauf einer Nachrichtenübertragung mit QoS-Level (a) 0, (b) 1 und (c) 2 [33] 
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mehrmaliges Versenden wird nicht ausgeschlossen. Der Sender wartet auf eine 
Empfangsbestätigung vom Empfänger und sendet die Nachricht erneut, wenn diese 
nach einer gewissen Zeit ausbleibt. QoS 2 stellt sicher, dass eine Nachricht genau 
einmal versendet wird. Dafür wird eine zweistufige Empfangsbestätigung einge- 
setzt, bei der der Publisher die erste Empfangsbestätigung des Subscribers bestä- 
tigt und wiederum eine Bestätigung dieser Bestätigung erwartet. Das QoS-Level 
bestimmt den Ablauf der Nachrichtenübertragung vom Publisher zum Broker und 
vom Broker zum Subscriber. Der Publisher erhält unabhängig vom verwendeten 
QoS-Level keine Rückmeldung, ob und an wie viele Clients der Broker die Nachricht 
gesendet hat. [32] [56] 

Ab QoS 1 wird einer Publish-Nachricht im Header eine Paket-ID hinzugefügt. 
Die auf eine Publish-Nachricht folgenden Antworten enthalten dann ebenfalls diese 
ID und können damit der Nachricht zugeordnet werden. Je höher das QoS-Level ist, 
desto langsamer ist durch die höhere Zahl der Kommunikationsschritte die Daten- 
übertragung. [33] 

Das Abonnieren eines Topics wird vom Broker immer mit einer Bestätigung 
beantwortet. Dabei muss das QoS-Level zwischen Broker und Subscriber nicht mit 
dem zwischen Broker und Publisher übereinstimmen. Das QoS-Level wird nur zwi- 
schen einem Client und dem Broker vereinbart. Topics lassen sich durch das Senden 
einer „Unsubscribe“-Nachricht wieder abbestellen. [33] [32] 

Für Einsatzfälle mit instabilen Netzwerken, bei denen Clients häufig die Ver- 
bindung zum Broker verlieren, wurden in MQTT die Funktionalitäten „Last Will 
and Testament“ und „Retained Message“ implementiert. Ein Client kann bei dem 
Verbindungsaufbau mit dem Broker einen sog. letzten Willen bestehend aus einem 
Topic und einer Nachricht angeben. Sobald der Broker eine Verbindungsunterbre- 
chung feststellt, wird dieser letzte Wille im Namen des Clients veröffentlicht. Eine 
mögliche Verwendung dieser Funktion ist das Senden der Nachricht „offline“ unter 
dem Topic „Status Sensor x“. [56] 

„Retained Messages“ sind Nachrichten, welche vom Broker unter dem angege- 
benen Topic gespeichert werden. Abonniert ein Client das entsprechende Topic, 
bekommt dieser zuerst die gespeicherte Nachricht zugesendet. Sobald ein Client 
eine „Retained Message“ unter demselben Topic versendet, wird die bisher unter 
diesem Topic gespeicherte Nachricht überschrieben. [56] 


Aufbau einer MQTT-Nachricht 

Abbildung 24 zeigt den Aufbau einer MQTT-Nachricht, welche Daten versendet. 
Diese besteht aus einem fixen Header mit einer Länge von 2 Byte, welcher den 
Nachrichtentyp enthält, also ob es sich z.B. um eine Publish-, Subscribe-, oder 
Connect-Nachricht handelt. Dem schließt sich die nur für die QoS-Level 1 und 2 
relevante Information an, ob die Nachricht ein Duplikat ist. Anschließend wird mit- 
geteilt, mit welchem QoS-Level die Nachricht versendet werden soll und ob es sich 
um eine „Retained Message“ handelt. Das zweite Byte enthält die Länge des sich 
anschließenden variablen Headers und der eigentlichen Nachricht. [3] 
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Field length B 
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Byte 2 header 
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Payload 
Byte m 


Abb. 24 Aufbau einer Publish-Nachricht in MQTT [17] 


Darauf folgt der variable Header, welche die Lange des Topics, das Topic selbst und 
bei QoS-Level 1 und 2 die Message ID enthält. Danach wird die eigentlich zu übertra- 
gende Nachricht angehangen. 

Die Lange des variablen Headers wird stark von der Lange des Topics bestimmt. 
Die geringstmögliche Lange des Headers insgesamt beträgt bei QoS 0 und einem 
Topic, welches aus nur einem Zeichen besteht, 5 Byte. 


5 IT-Konzept zur 
kommunikationstechnischen Optimierung 
des Basiskonzepts 


Es soll das bestehende Sensorkonzept unter Verwendung der vorhandenen Hard- 
ware kommunikationstechnisch optimiert werden. Das bisher eingesetzte Anwen- 
dungsprotokoll HTTP wird durch das in Kapitel 4.3 vorgestellte MOTT ersetzt. Es 
erfolgt ein Einsatz in einer als stabil anzusehenden Netzwerkumgebung, sodass 
unter dem Ziel der geringen Sendedauer eine Umsetzung mit QoS-Level 0 erfolgt. 
Die dafür notwendigen und im praktischen Teil dieser Bachelorarbeit durchgeführ- 
ten softwaretechnischen Anpassungen werden in diesem Kapitel vorgestellt. 


5.1 Softwaretechnische Implementierung der 
Datenübertragung mittels MQTT-Protokoll 


Zur Nachrichtenübermittlung über MQTT wird ein Broker benötigt, welcher die 
Kommunikation verwaltet. Deshalb wurde zunächst auf dem Raspberry Pi unter 
Verwendung der Open-Source-Software Mosquitto ein MQTT-Broker eingerichtet. 
Die Aufgaben des RPIs ändern sich damit. Die Funktion als WLAN-Router bleibt wei- 
terhin bestehen, die des Webservers wird durch die des Brokers ersetzt. 

Als nächster Schritt erfolgte eine Einarbeitung in die verwendete Program- 
miersprache LUA und die Funktionsweise der Kommunikation mit dem Beschleu- 
nigungssensor über ein SPI-Interface. LUA arbeitet mittels ereignisgesteuerten 
Aktionen. Treten bei der Programmierung im Voraus festgelegte und von außen 
kommende Ereignisse ein, wird eine bestimmte Aktion ausgelöst. 

Anschließend konnte das bisherige auf dem Microcontroller ablaufende Mes- 
sprogramm analysiert werden, welches die Messwerte ausliest und mittels HTTP 
versendet. Darauffolgend wurde die Implementierung von MQTT in das Programm 
durchgeführt, wodurch sich einige Unterschiede ergeben. Es wird zum Erstellen 
des Skriptteils mit der Datenübertragung eine andere Bibliothek angesprochen, 
weshalb andere Befehle verwendet werden. Zudem besitzt MQTT mit der Publish/ 
Subscribe-Architektur ein anderes Konzept zur Datenübertragung. 

Bei der Programmierung muss die begrenzte Größe des Speichers des Micro- 
controllers beachtet werden. Wird während der Skriptausführung mehr Arbeitsspei- 
cher als die zur Verfügung stehenden 50 kByte benötigt, wird der Programmablauf 
unterbrochen und das Transceivermodul führt einen Neustart durch. Die Länge der 
erstellten Programme ist ebenfalls begrenzt. Der Programmspeicher besitzt eine 
Größe von 4 MByte und beinhaltet zudem die Firmware sowie die eingebundenen 
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LUA-Bibliotheken, welche bspw. zum Aufbau der WLAN-Verbindung, zur Kommuni- 
kation mittels SPI-Interface oder zur Datenübertragung durch MQTT benötigt werden. 


Programmablauf 

In Abbildung 25 ist der prinzipielle Ablauf des Messprogramms mit Einsatz von 
MOTT abgebildet. Es ist in die zwei Skripte Initialisierungsskript und Messskript 
unterteilt. Der auskommentierte LUA-Code des Initialisierungsskripts befindet sich 
in Anhang 1, der des Messkriptes in Anhang 2. 
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I 
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Initialisierungsskript 
Abb. 25 Ablauf des MQTT-Programms 


Das Initialisierungsskript startet, sobald der Microcontroller aus dem Sleep-Modus 
aufgewacht ist. Es erfolgt zunächst eine Abfrage, ob ein WLAN vorhanden ist. Falls 
kein WLAN existiert, wird der Microcontroller wieder in den Sleep-Mode versetzt. 
Wird ein bestehendes Netzwerk gefunden, wird mit diesem eine Verbindung aufge- 
baut und anschließend das Messskript aufgerufen. 

Das Messskript läuft prinzipiell wie in Abbildung 25 dargestellt ab. Zunächst 
wird ein MQTT-Client eingerichtet, welcher im späteren Verlauf des Programms 
MOTT-Nachrichten unter dem Topic „ADIS“ veröffentlicht. Anschließend wird eine 
Verbindung zum Broker hergestellt, welche dauerhaft zur Datenübertragung zur 
Verfügung steht. Ist der Verbindungsaufbau erfolgreich verlaufen, erfolgt die Kom- 
munikation mit dem Beschleunigungssensor über das SPI-Interface. Es werden Ein- 
stellwerte übermittelt und eine Messung des Sensors ausgelöst. 

Der Sensor misst und speichert 3072 Werte zwischenzeitlich in einem Puffer. 
Dieser Zwischenspeicher wird durch das Messskript schrittweise über die SPI- 
Verbindung ausgelesen. Das Versenden der Messwerte sollte paketweise erfolgen. 
Zwar ist das Übertragen von Einzelwerten möglich, aber auch mit MQTT wird dafür 
eine größere Zeitdauer als bei der Übermittlung von Datenpaketen benötigt. Die 
Ursache dafür besteht darin, dass in dieser Variante 3072 Nachrichten erstellt und 
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versendet werden müssen, was durch die begrenzten Ressourcen des Microcontrol- 
lers eine gewisse Zeit in Anspruch nimmt und allein durch die von TCP und MQTT 
verursachten Header eine größere Datenmenge verursacht. Der Header einer 
MOTT-Nachricht besitzt inklusive des TCP-Headers eine Mindestgröße von 22 Byte. 
Zur Übertragung des Topics „ADIS“ werden 4 Byte benötigt, sodass zur Übermitt- 
lung von 3072 Nachrichten insgesamt (3072 * 26 Byte =) 79.872 zu übertragende und 
vor allem durch den Microcontroller zu verarbeitende Byte entstehen. 

Um Datenpakete zu bilden, werden die schrittweise ausgelesenen Einzelwerte 
in einer Tabelle auf dem Microcontroller zwischengespeichert. Wurden 128 Werte 
ausgelesen, werden diese mit Kommas getrennt zu einer Zeichenkette (engl. String) 
zusammengefügt. Nachdem diesem String als Metadaten die Achsenposition und 
die verwendete Filtereinstellung hinzugefügt wurden, wird dieser unter dem Topic 
„ADIS“ als MQTT-Nachricht veröffentlicht. Das Erstellen eines Nachrichtenheaders 
mit dem Messskript wie bei HTTP entfällt. 

Die maximale durch MQTT übermittelbare Nachrichtengröße beträgt 256 MByte. 
[47] Ein String besitzt in LUA hingegen eine maximal zulässige Länge von 2048 Byte. 
Soll die Anzahl an Messwerten je Datenpaket identisch sein, ergibt sich durch diese 
Begrenzung eine maximale Paketgröße von 128 Werten. Bei der nächstgrößeren 
möglichen Anzahl von 192 Werten je Paket würde durch die Messwerte, die Kommas 
sowie die angefügten Metadaten die Stringlänge von 2048 Byte überschritten werden. 

Es wurde die Laufzeit des Messskriptes mit verschiedenen Paketgrößen ermit- 
telt. Werden 128 Werte je Datenpaket ausgelesen und versendet, ist die Gesamtlauf- 
zeit am geringsten. Dieses Ergebnis wurde mit dem in Kapitel 6 vorgestellten Mess- 
szenario und einer Paketgröße von 64 Werten überprüft. Es wurde festgestellt, dass 
bei 64 Messwerten je Paket die gesamte Sendezeit 2 s länger andauert als bei Verwen- 
den von 128 Werten je Paket, weshalb eine Paketgröße von 128 Werte eingesetzt wird. 

Das erfolgreiche Versenden eines Datenpakets als MQTT-Nachricht dient als 
Ereignis, um das Auslesen und Versenden des nächsten Pakets auszulösen. Es 
wird so lange abwechselnd der Zwischenspeicher schrittweise ausgelesen und die 
Daten in Paketen mit je 128 Werten versendet, bis alle 3072 Messwerte erfasst und 
insgesamt 24 Datenpakete übermittelt wurden. Wird die Verbindung zum Broker 
innerhalb des Ablaufs des Messskriptes unterbrochen, wird zum erneuten Verbin- 
dungsaufbau das Initialisierungsskript aufgerufen. Sind alle Messwerte ausgelesen, 
nehmen der Sensor und das Transceivermodul wieder den Sleep-Modus ein. 


5.2 Softwaretechnische Anpassungen der Leitwarte 


Durch das Verwenden von MQTT als Protokoll zur Netzwerkkommunikation ist eine 
Datenanalyse und Kennwertbildung mittels Matlab-Applikation wie im Ausgangs- 
stand nicht möglich, da diese nicht auf der Basis von MQTT kommunizieren kann. 
Zudem verwaltet der Raspberry Pi nun als Broker die Kommunikation und loggt die 
Daten nicht mehr mittels PHP-Skript in einer CSV-Datei. Diese Aufgabe wird nun 
von der Leitwarte übernommen. 

Bei der Umsetzung des Alternativkonzepts wurde deshalb auf der Clientseite 
der Leitwarte die Open-Source-Software Node-Red verwendet. Diese wurde von IBM 
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entwickelt, 2013 veröffentlicht und istim Gegensatz zu Matlab kostenfrei. Node-Red 
ist plattformunabhängig und läuft deshalb auch auf Smartphones oder Einplatinen- 
rechnern wie z.B. dem Raspberry Pi. 

Die Software besitzt eine webbasierte Benutzerschnittstelle, die mit einem 
Browser aufrufbar ist. Auf dieser Weboberfläche können auf Grundlage einer daten- 
flussbasierten Programmierung vorgefertigte grafische Funktionsbausteine aus 
einer Liste ausgewählt, auf der Oberfläche platziert, anschließend konfiguriert und 
mittels „Drag & Drop“-Aktion miteinander verbunden werden. Es existieren Module 
mit Eingängen, welche als Senke Daten empfangen, Elemente mit Ausgängen zum 
Versenden von Daten als Quellen sowie Bausteine, welche beide Funktionen verei- 
nen. Abbildung 26 zeigt eine Auswahl möglicher Funktionselemente in Node-Red. 
Es sind z.B. Bausteine für eine Kommunikation über HTTP oder MQTT vorhan- 
den. Andere Elemente führen eine FFT durch, bilden einen softwaretechnischen 
PID-Regler oder versenden Informationen automatisiert als E-Mail. Zudem können 
in JavaScript geschriebene Funktionen eingefügt werden, womit bei Beherrschung 
dieser Programmiersprache große Funktionsmöglichkeiten entstehen. [69] 
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Abb. 26 Auswahl möglicher Funktionselemente in Node-Red 


Die Module werden anschließend in einem Fenster in der Weboberfläche konfigu- 
riert. Abbildung 27 zeigt die Konfiguration eines MQTT-Clients, welcher das Topic 
„ADIS“ abonniert. Die Angabe der IP-Adresse des Brokers, des Topic-Namens und 
des gewünschten QoS-Level ist dafür ausreichend. 
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Abb. 27 Konfiguration eines MQTT-Subscriber-Clients 


Mit Node-Red kann eine grafische Darstellung und die Eingabe von Werten auf 
einem sog. Dashboard erfolgen. Dieses fungiert als Webserver und kann tiber eine 
URL von jedem beliebigen Gerat im Netzwerk aufgerufen werden. 

In der aktuellen Umsetzung des Alternativkonzepts wird das Node-Red auf dem 
Rechner der Leitwarte ausgeführt und übernimmt das Loggen der Daten in eine 
CSV-Datei, was im bisherigen Konzept auf dem Raspberry Pi erfolgt ist. Dazu wurde 
der in Anhang 3 ersichtliche Programmfluss erzeugt. Dieser erstellt zunächst einen 
MOTT-Client, welcher das entsprechende Topic „ADIS“ abonniert, unter dem das 
Transceivermodul die Messdaten veröffentlicht. Eine Anforderung an das Mitloggen 
der Daten besteht im Erstellen eines neuen Ordners je Tag und einer neuen Mess- 
datei je Stunde, damit die Größe einer Messdatei überschaubar bleibt. Die darauf- 
folgenden Funktionselemente überprüfen das Vorhandensein dieser Ordner bzw. 
Dateien und erstellen diese falls nötig neu. Die Namen enthalten das aktuelle Datum 
bzw. die Uhrzeit. Eine neue CSV-Datei wird inklusive Spaltenüberschriften angelegt. 
Zudem wird den Messdaten beim Loggen ein Zeitstempel hinzugefügt. 

Die mit dem Node-Red erstellte CSV-Datei kann mit der Matlab-Applikation ein- 
gelesen werden und damit die bisherige Darstellung der Leitwarte erfolgen. Alter- 
nativ lassen sich auch mit Node-Red kompliziertere Aufgaben wie z.B. eine FFT 
umsetzen, sodass eine Übertragung der Funktionen der Matlab-Applikation wie die 
Errechnung und Darstellung des Diagnosekennwerts und die Darstellung des Zeit- 
sowie Frequenzsignals denkbar ist. Da Node-Red als Webserver fungieren kann, 
könnten diese Darstellungen zudem von allen Geräten wie z.B. Smartphones und 
Laptops mit einem Webbrowser angezeigt werden. Die Voraussetzung dafür ist, dass 
sich diese Geräte im gleichen WLAN wie die Leitwarte befinden. 
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5.3 Beschreibung des Gesamtkonzepts im Sollzustand 


Es ergibt sich mit den in Kapitel 5.1 und 5.2 beschriebenen Veränderungen das in 
Abbildung 28 dargestellte Gesamtkonzept. Die Hardware besteht unverändert wie 
auch im bisherigen Konzept aus dem Raspberry Pi, dem Sensorknoten mit u.a. 
dem Beschleunigungssensor und dem Transceivermodul sowie dem Leitwarten- 
Rechner. Der Sensorknoten befindet sich räumlich getrennt von der Leitwarte. Es 
sollen die vom Beschleunigungssensor gemessenen Werte kabellos an die Leitwarte 
zu übertragen werden. 


Leitwarte / Analyse- 
Client 


Datenloggen via 
Node-Red 
(MQTT-Client) 
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<> MOTT- N 
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Verwaltung 


Sensorknoten 


Abb. 28 Gesamtkonzept Nachrichtenübertragung mittels MQTT 


Der Raspberry Pi besitzt als Kommunikationszentrum zwei Aufgaben. Zum einen 
spannt er als Router ein WLAN auf. Zusätzlich verwaltet der RPI als Broker die über 
dieses Netzwerk ablaufende Kommunikation. Als MQTT-Clients befinden sich in 
diesem WLAN das Transceivermodul und die Leitwarte. Der Microcontroller ver- 
öffentlicht als Publisher-Client die aus dem Sensor ausgelesenen Messdaten unter 
dem Topic „ADIS“. Die Leitwarte teilt als Subscriber-Client dem Broker einmalig bei 
Verbindungsaufbau mit, dass alle Nachrichten abonniert werden sollen, welche 
unter diesem Topic veröffentlicht werden. Werden Daten vom Transceivermodul 
mit dem Topic „ADIS“ versendet, nimmt der Broker diese entgegen und leitet diese 
an alle Clients weiter, welche dieses Topic abonniert haben. Die Leitwarte erhält die 
versendeten Messdaten und loggt diese mit einem Zeitstempel in einer CSV-Datei. 
Dieses Sensorkonzept bietet im Vergleich zu dem bestehenden Konzept zusätz- 
liche Möglichkeiten im Einbinden weiterer Geräte, welche die Messdaten zu wei- 
teren Anzeige- oder Analysezwecke erhalten könnten. Es sind weitere Geräte als 
MOTT-Clients denkbar, die sich in dem WLAN befinden und durch das Abonnieren 
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des Topics „ADIS“ ebenfalls die Nachricht vom Transceivermodul erhalten. Alterna- 
tiv kann auf der Leitwarte mit Node-Red ein sog. Dashboard eingerichtet werden, 
welches bspw. die Messwerte oder die Analysekennwerte anzeigt. Dieses Dashboard 
fungiert als Webserver, kann von jedem Gerät mit einem Browser wie z.B. einem 
Smartphone oder einem weiteren Laptop aufgerufen und damit die entsprechenden 
Darstellungen angezeigt werden. 


6 Messtechnische Untersuchung 


6.1 Messtechnische Strategie zur Ermittlung der 
Sendeleistung und der Sendedauer 


Durch den Einsatz des leichtgewichtigen MQTT-Protokolls zur Datenübertragung 
wird eine Verbesserung der Energieeffizienz vor allem durch die Verringerung der 
zur Datenübertragung erforderlichen Sendedauer vermutet. Zudem ist die mes- 
stechnische Aufnahme des realen Lastprofils mit den verschiedenen Betriebszu- 
ständen des Sensorknotens von Interesse, für die die Messwerte inklusive eines 
Zeitsignals ermittelt werden müssen. Diese Informationen werden anhand des im 
Folgenden beschriebenen Messkonzepts gewonnen. 

Um die Leistungsaufnahme des Sensorknotens abschätzen zu können, werden 
die beiden Größen Spannung (U) und Strom (I) benötigt, da der folgende Zusam- 
menhang gilt: 


P=U*l (6.1) 


Die durch die Spannungsquelle bereitgestellte Spannung ist in diesem Messs- 
zenario weitgehend konstant, weshalb im weiteren Verlauf die Stromstärke als 
relevante Messgröße betrachtet wird, welche sich im Zeitverlauf ändert. Wird die 
Stromstärke zusammen mit einem Zeitsignal aufgenommen, kann ein Lastprofil 
erstellt werden. Mit diesen Daten lässt sich die Sendedauer sowie die Stromauf- 
nahme des Sensorknotens bestimmen und eine Aussage treffen, inwieweit diese 
durch den Einsatz von MQTT gegenüber HTTP verringert und damit entsprechend 
die energetische Lebensdauer des Sensorknotens vergrößert wurden. In der Sende- 
dauer bildet sich zudem die Sendeleistung des Transceivermoduls ab. Die Anzahl 
zu übertragender Messdaten bleibt konstant. Sinkt nun die Sendedauer, so ist die 
Sendeleistung gestiegen. 


6.1.1 Messschaltung 


Im Gegensatz zur Spannung kann der Strom nur über indirekte Methoden ermit- 
telt werden. Eine Möglichkeit bietet das vereinfacht in Abbildung 29 dargestellte 
Verwenden eines mit dem Verbraucher in Reihe geschalteten Messwiderstands 
(engl. Shunt) R,,,,, mit bekannter Größe, dessen Spannungsabfall über ein parallel 
geschaltetes Voltmeter gemessen wird. Transceiver und Beschleunigungssensor 
werden zur Darstellung in einem Verbraucher R, zusammengefasst. In einer Rei- 
henschaltung werden alle Bauteile von einem Strom I gleicher Größe durchflossen. 


http://doi.org/10.33968/9783966270069.0006 
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R - Messwiderstand 


Mess 


Ri, - Transceiver + Sensor > Last 


Abb. 29 vereinfachte Low-Side-Messschaltung 


Durch Messung der über R,,,,, abfallenden Spannung U,,,.. kann wie folgt der Strom 
berechnet werden, welcher auch den Sensorknoten durchfließt: 


U 
[= Mess (6.2) 
R 


Mess 

Der Stromfluss der Messchaltung teilt sich auf den Messwiderstand und das Volt- 
meter auf. Es wird ein spannungsrichtiges Messen der über den Messwiderstand 
abfallenden Spannung U „e ermöglicht. Durch die Parallelschaltung entspricht der 
Spannungsabfall über dem Messwiderstand der mittels des Voltmeters gemessenen 
Spannung. 

Es wurde wie in Abbildung 29 dargestellt eine sog. Low-Side-Messung durch- 
geführt, bei der der Messwiderstand zwischen dem Sensorknoten und der Masse 
der Spannungsquelle geschaltet wird. Die Nachteile dieses Messansatzes bestehen 
darin, dass der Massepegel aus Sicht der Last angehoben wird und Kurzschlüsse 
unerkannt bleiben. [73] 

Diese Nachteile lassen sich mit einer wie in Abbildung 30 gezeigten High-Side- 
Schaltung umgehen, mit der eine Messung an der Versorgungsspannungsleitung 
zwischen Spannungsquelle und Last stattfindet. In den meisten Fällen befindet sich 
an der Stelle des Voltmeters in der Abbildung eine Signalaufbereitungsschaltung, 
welche die Messwerte verstärkt und die bei der High-Side-Messung gegenüber der 
Low-Side-Messung komplexer und teurer ist. [73] 

Es wurde ein Messwiderstand mit einem realen Wert von 1,2 Q verwendet. Bei 
Einsatz eines kleineren Messwiderstandes von z.B. 0,1 Q wäre der zu messende 
Spannungsabfall sehr klein und damit nur mit größerem Aufwand erfassbar. Um 
den zusätzlich verursachten Leistungsabfall über die Messschaltung so gering wie 
möglich zu halten, wird andererseits ein möglichst geringer Messwiderstand ange- 
strebt. Bei Verwendung eines größeren Messwiderstandes von z.B. 10 Q steigt die 
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vahmeter 


R 
Ry, - Transceiver + Sensor > Last 


Mess 7 Messwiderstand 


Abb. 30 vereinfachte High-Side-Messung 


über diesen Widerstand abfallende Spannung. Laut den Datenblättern wird im Sen- 
debetrieb ein Strom von maximal etwa 220 mA erwartet (s. Kapitel 3.4). Bei einem 
Messwiderstand von 10 Q würde sich ein Spannungsabfall von 2,2 Vergeben. Bei 5 V 
Versorgungsspannung blieben dann noch etwa 2,8 V übrig, mit denen der Micro- 
controller ESP8266 nicht betrieben werden könnte. 

An der Stelle des Voltmeters in Abbildung 29 befindet sich in der realen Mess- 
schaltung der Microcontroller Arduino Nano. Dieser ermöglicht ein Loggen der 
Spannung im Zeitverlauf, was mit den zur Verfügung stehenden Multimetern 
nicht realisiert werden kann. Im Vergleich zu dem als Transceivermodul einge- 
setzten ESP8266 besitzt der Arduino Nano mit einer Taktfrequenz von 16MHz, 
32kB Flash-Speicher und 2kB Arbeitsspeicher deutlich geringere Leistungsdaten 
und kein WLAN-Modul, dafür aber 8 analoge Eingänge mit einem integrierten 
10-Bit-ADC. [5] 

Die über den Messwiderstand abfallende Spannung wird als analoges Signal 
an einen Eingang des Arduinos angelegt und durch dessen integrierten ADC digi- 
talisiert. Die Stromversorgung des Arduinos erfolgt extern über ein an einen PC 
angeschlossenes USB-Kabel. Über diesen USB-Anschluss wird auch das Anzeigen 
der ausgelesenen Werte ermöglicht. Mithilfe der Arduino-Programmierumgebung 
wurde das im Anhang 4 abgebildete Messskript erstellt, welches auf dem Arduino 
ausgeführt wird und alle 100 ms die digitalisierten Messwerte aus dem ADC ausliest 
sowie ein Zeitsignal hinzufügt. Die Daten werden so mit einem Zeitsignal geloggt und 
auf dem seriellen Monitor in der Arduino-Programmierumgebung auf dem Rechner 
angezeigt. Von dort werden diese zur weiteren Auswertung in Excel kopiert. 

Bei der Digitalisierung wird einem Bereich von Analogwerten ein diskreter Digi- 
talwert zugeordnet. Ein 10-Bit-ADC stellt 2° = 1024 Werte als sog. Quantifizierungs- 
stufen zur Verfiigung. Mit einer Eingangsspannung von 5 V ergibt sich die folgende 
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Auflösung des Wandlers, welche die Breite des Analogwertebereichs darstellt, die 
eine Quantifizierungsstufe beinhaltet [7]: 


ss U 5V 
Auflösung U,,- = Æ = — = 4,8 mV 6.3 
Inc” 1024 
Auflösung U,,.  .-.. Auflösung des Spannungswertes durch ADC 
U, .. Versorgungsspannung ADC/Arduino (5 V) 
n .. Anzahl Quantifizierungsstufen (1024 bei 10-Bit-ADC) 


Für den Strom ergibt sich mit dem realen Widerstandswert von 1,2 Q damit als 
Auflösung: 


Auflösung Une _ 48mV _ AmA (6.4) 
R 1,2Q 


Mess 


Auflösung lane = 


Auflösung | Auflösung des Stromwertes durch ADC 


ADC 
Die Messunsicherheit dieses Messaufbaus liegt somit allein aufgrund des 
sog. Quantifizierungsfehlers durch die Auflösung des Wandlers und ohne Berück- 
sichtigung anderer Ursachen wie z.B. Verstärkungs- oder Linearitätsfehlern bei 
4 mA. [8] 

Laut den in Abschnitt 3.4 dargestellten Datenblattwerten ergibt sich ein zu reali- 
sierender Messbereich von etwa 0 bis 220 mA. Mit einer Auflösung des Messsystems 
von 4 mA stünden nur 55 Quantifizierungsstufen zur Abbildung dieses Bereiches zur 
Verfügung und eine Angabe wäre vor allem bei den kleinen Messwerten in Bezug 
auf die Größe des Wertes ungenau. Es wurde deshalb die Vorgabe gewählt, auf 1 mA 
aufzulösen. Laut Goldener Regel der Messtechnik muss zehnmal genauer gemessen 
werden, als der Wert angegeben werden soll, sodass eine Messung auf 0,1 mA erfol- 
gen muss. 

Mit dem 10-Bit-ADC des Arduinos ist dies nicht möglich, weshalb ein Operations- 
verstärker (OPV) eingesetzt wird. Der OPV verstärkt den analogen Spannungswert, 
bevor dieser in den Arduino eingelesen wird und ermöglicht eine feinere Auflösung 
des Messwertes. Alternativ wäre anstatt des OPVs der Einsatz eines 16-Bit-ADCs mit 
65536 (= 2*6) Quantifizierungsstufen und einer entsprechend kleineren Auflösung 
denkbar. 

Mit Einsatz des OPVs ergibt sich der in Abbildung 31 dargestellte Aufbau der 
Messschaltung. Der Messwiderstand befindet sich zwischen dem Sensorknoten und 
dem Masseanschluss der Spannungsquelle. Die Versorgungsspannung des OPVs 
von 5 V wird durch den Arduino bereitgestellt. Der OPV wird mit den in der Abbil- 
dung als R, und R, bezeichneten Widerständen so beschaltet, dass dieser als nicht- 
invertierender Gleichspannungsverstärker dient. Für den Verstärkungsfaktor v gilt 
der folgende Zusammenhang: 
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v=1+ i [48] (6.5) 


v .. Verstärkungsfaktor 


Abbildung 32 zeigt die Verstärkungskennlinie des OPVs für einen Verstärkungsfak- 
tor von 10 sowie von 20. Der Anstieg der Linie entspricht dem Verstärkungsfaktor. 
Ein idealer OPV kann die Eingangsspannung U, maximal auf die Höhe seiner Ver- 
sorgungsspannung U, verstärken, welche in diesem Messsystem 5 V beträgt. Bei rea- 
len OPVs reicht der Bereich der Ausgangsspannung U, nicht vollständig an U, heran. 
Der eingesetzte OPV „LM358“ ermöglicht laut Datenblatt [48] eine Ausgangsspan- 
nung mit einer Größe von bis zu U, - 1,5V, sodass sich eine maximale Ausgangs- 
spannung U, „von (5V-1,5V =) 3,5V ergibt. 

Der Verstärkungsfaktor ist deshalb so zu wählen, dass der größte Wert des abzu- 
bildenden Messbereiches auf maximal 3,5 V verstärkt wird. Bei 220 mA als höchsten 
Wert des Messbereiches fällt über dem Messwiderstand die folgende Spannung ab, 
welche die Eingangsspannung U, des OPVs ist: 


U, = 1 ax * Rmess = 220 MA*1,2Q = 264 mV (6.6) 
Us „=-~  Eingangsspannung OPV bei Imax 
Imax + größter Stromwert des Messbereiches 


In Abbildung 32 ist erkennbar, dass mit v = 20 ab 175 mV alle Werte auf 3,5 V ver- 
stärkt werden. Alle darüberliegenden Eingangsspannungswerte werden ebenfalls 
auf 3,5 V verstärkt. Um den Messbereich bis 220 mA vollständig abzubilden, wäre 
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Verstärkungskennlinie OPV mit U, = 5V 
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Abb. 32 Verstärkungskennlinie OPV 


dieser Verstärkungsfaktor zu hoch gewählt und nicht geeignet. Der Verstärkungs- 
faktor lässt sich als Verhältnis der Ausgangs- zur Eingangsspannung ausdrücken, 
sodass sich für den abzubildenden Messbereich der folgende maximale Verstär- 
kungsfaktor ergibt: 


P E > 
m™ Ur 0,264V 


max 


13,3 (6.7) 


maximaler Verstärkungsfaktor bei Messbereich I = 0 ... 220 mA 
U, .. maximale Ausgangsspannung OPV bei V,=5 V 
Ur ..Eingangsspannung OPV bei I = 220 mA 


Es wird bei einer größeren Verstärkung durch die Mitverstärkung der Messfeh- 
ler eine stärkere Verfälschung der Messwerte hervorgerufen. Gleichzeitig wird 
zur möglichst feinen Auflösung der Messwerte eine hohe Verstärkung angestrebt. 
Zudem verhält sich ein System im unteren Bereich der Kennlinie zumeist nichtli- 
near. Mit einer größeren Verstärkung befinden sich die kleineren Messwerte eher 
im linearen Bereich. 

Es wurde deshalb ein Verstärkungsfaktor in der Größenordnung von Va ange- 
strebt. Laut Gleichung 6.5 ist die Verstärkung abhängig von den Werten der Wider- 
stände, mit denen der OPV beschaltet wird. Es wurden Widerstände mit den realen 
Werten R, = 10,01 kQ und R, = 100,6 KQ gewählt, mit denen sich unter Verwendung 
der Gleichung 6.5 der folgende Verstärkungsfaktor ergibt: 
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v=1+— =1+—— =11,05 (6.8) 


Das über dem Messwiderstand abfallende Spannungssignal wird durch den OPV mit 
einem Faktor von 11,05 verstärkt. Diese Spannung wird an den analogen Eingang des 
Arduinos angelegt und anschließend digitalisiert. Die bei einem Strom von 220 mA 
über den Messwiderstand abfallende Spannung U, von 264 mV wird auf eine Aus- 
gangsspannung von (0,264V * 11,05 =) 2,9 V verstärkt. Es stehen nun (55 * 11,05 =) 
608 Quantifizierungsstufen zur Auflösung des Messbereiches von 0 bis 220 mA zur 
Verfügung, sodass eine feinere Auflösung des Messwertes erfolgt. Es wird nun fol- 
gende Auflösung des Stroms erreicht: 


Auflösung lapc _ 4 MA 


Auflösung I = 
v 11,05 


= 0,36 mA = 0,4 MA (6.9) 


Auflösung | Auflösung des Stromwertes durch ADC (siehe Gleichung 6.4) 


ADC 
Die angestrebte Messung auf 0,1 mA wird nicht erreicht. Eine Messung auf 0,4 mA 
wird für den Messzweck des Ermittelns des Lastprofils mit den entsprechenden 
Zeitdauern der einzelnen Betriebsmodi und der Abschätzung des Stromverbrauchs 
als ausreichend erachtet. 

Mit dem gewählten Verstärkungsfaktor von 11,05 wird bei einem Strom von 
220 mA die maximale Ausgangsspannung des OPVs von 3,5 V nicht vollständig aus- 
genutzt. Der folgende Stromfluss im Messwiderstand verursacht einen Spannungsab- 
fall, welcher mit einem Verstärkungsfaktor von 11,05 auf genau 3,5 V verstärkt wird: 


Uz 3, 5V 


I _ max 
MX Rigel Ae 1106 


= 264 mA (6.10) 


* 
ess 


Das aufgebaute Messsystem besitzt somit einen Messbereich von 0 bis 264 mA und 
eine Auflösung von 0,4 mA. 

Mit dem auf dem Arduino ablaufenden Messskript (s. Anhang 4) erfolgt die 
folgende Berechnung 6.12, welche ein direktes Anzeigen des indirekt gemessenen 
Stroms in dem seriellen Monitor auf dem Rechner ermöglicht. x stellt den aus dem 
ADC ausgelesenen digitalisierten Wert dar. 


| = Auflösung |* x (6.11) 
x ... aus ADC ausgelesener digitalisierter Wert 
mit Gleichung 6.3 ... Auflösung U,yc = Us 
n 
_ Auflösung U 


mit Gleichung 6.4 ... Auflösung lape =——— ADC und 
Mess 
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Auflösung I anc 


mit Gleichung 6.9 ... Auflösung I = ergibt sich: 
Siy 
/=—__ (6.12) 
v* Res 


6.1.2 Übersicht über gesamten Messaufbau 


Das Ziel des in Abschnitt 6.1.1 beschriebenen Messkonzepts besteht in der Ermitt- 
lung der Stromaufnahme des Sensorknotens im Zeitverlauf. Abbildung 33 zeigt 
die konkrete Verschaltung aller Komponenten des Messaufbaus. Es sind die drei 
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Abb. 33 Uberblick gesamter Aufbau mit Sensorknoten, Spannungsversorgung und Mess- 


schaltung 


Messtechnische Strategie zur Ermittlung der Sendeleistung und der Sendedauer 59 


Tab.4 im Messszenario verwendete Bauteile 


Sensorknoten Entwicklerboard NodeMCU mit Microcontroller ESP8266 und 
integriertem Spannungswandler 5 V auf 3,3 V 


Beschleunigungssensor ADIS 16223 
Flip-Flop SN74HC74N 
Pullup-/Pulldown-Widerstände 10 kQ bzw. 100 kQ 


Spannungsversorgung Spannungswandler 5 V auf 3,3 V 
Power-Board 


Messschaltung Arduino Nano 
Operationsverstarker LM358N 
10 kQ- und 100 kQ-Widerstand 
Messwiderstand 1 Q 


Baugruppen Sensorknoten, Spannungsversorgung und Messchaltung mit den in 
Tabelle 4 aufgeführten Bauteilen zu erkennen. 

Die Spannungsversorgung der Bauteile des Sensorknotens erfolgt über einen 
5 V-USB-Anschluss und ein Power-Board, von welchem aus die Spannung über Jum- 
per-Kabel abgegriffen werden kann. Zwei Spannungswandler wandeln die Span- 
nung auf die benötigten 3,3 V. Ein Spannungswandler ist auf dem Entwicklerboard 
des Transceivermoduls integriert. Er verursacht im Sleep-Modus einen Strom von 
etwa 10 mA. Dieser Wandler kann nicht zur Versorgung der anderen Komponenten 
des Sensorknotens verwendet werden, weshalb ein zweiter Spannungswandler ein- 
gesetzt wird. 

Der Messwiderstand befindet sich an der in Abbildung 33 eingezeichneten 
Messstelle zwischen dem Masseanschluss des Powerboards und dem eingezeich- 
neten Widerstand „Sensorknoten“, welcher alle Komponenten des Sensorknotens 
zusammenfasst und zudem den externen Spannungswandler enthält. Es wird durch 
diese Messstelle die Stromaufnahme aller Komponenten des Sensorknotens sowie 
des externen Spannungswandlers erfasst. Nicht berücksichtigt wird die Stromauf- 
nahme des Power-Boards. 

Die folgende Tabelle 4 fasst die verwendeten Bauteile des in Abbildung 33 darge- 
stellten gesamten Messaufbaus zusammen. 

In diesem Messkonzept wird die Versorgungsspannung einzelner Bauelemente 
von insgesamt vier verschiedenen Komponenten zur Verfügung gestellt. Die fol- 
gende Tabelle 5 gibt einen Überblick, welches Bauteil von welcher Spannungsquelle 
versorgt wird. 

Der reale Aufbau wurde auf Steckplatinen und mit Jumper-Kabeln durchge- 
führt. Gegenüber einem festen Aufbau ist er mit Stecken der entsprechenden Kom- 
ponenten und Kabel simpel zu realisieren, besitzt aber den Nachteil häufig auftre- 
tender Fehler durch Spannungsverluste aufgrund von Wackelkontakten und durch 
Bildung ungewollter Kapazitäten. 
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Tab.5 Übersicht Spannungsversorgung 


5V Power-Board 3,3V-Wandler PC Arduino Nano 


3,3 V-Wandler X 


Entwicklerboard mit ESP8266 X 


Arduino Nano X 


Sensor X 


Flip-Flop X 


OPV X 


6.2 Ergebnisse der Untersuchung und Gegenüberstellung 
der Resultate 


Der Arduino wird an einen Rechner angeschlossen. Es werden in einem sog. seri- 
ellen Monitor der Arduino-Programmierumgebung die gemessenen Stromwerte 
und die Zeitdauer angezeigt, welche seit Öffnen des seriellen Monitors vergangen 
ist. Das Auslesen des ADCs und damit die Erfassung des Stroms erfolgt alle 100 ms. 
Diese Werte wurden von dort aus in ein Excel-Dokument kopiert, in dem eine Aus- 
wertung vorgenommen wurde. 

Es wurden etwa 500 s mit 15 Messzyklen des MQTT-Programms und 16 Zyk- 
len mit HTTP ausgewertet. Für das Messszenario wurde im Messskript eine Dauer 
des Sleep-Modus von 10 s hinterlegt. Es erfolgte eine Einteilung der Messwerte in 
die Betriebszustände Grundzustand, Sendebetrieb und Sleep-Modus analog zu 
Kapitel 3.4. Der Betriebszustand Messen wurde nicht mehr separat betrachtet, da 
sich die Stromaufnahme nicht von der des Sendebetriebs unterscheidet. Der Zustand 
Sendebetrieb enthält nun zusätzlich die etwa 0,7 s des Messvorgangs. 

Abbildung 34 zeigt die graphische Darstellung der Stromaufnahme des Sensor- 
knotens bei Ablaufen des MQTT-Messprogramms mit 15 Messzyklen im Verlauf der 
Zeit. Eine entsprechende Darstellung für HTTP befindet sich in Anhang 5. Es sind im 
Zeitverlauf Stromaufnahmen verschiedener Größenordnung zu erkennen, welche die 
unterschiedlichen Betriebszustände kennzeichnen. Innerhalb der einzelnen Betriebs- 
modi schwanken die Werte. Deshalb wurde für jeden der Messzyklen die Länge der 
einzelnen Betriebsmodi bestimmt sowie der Mittelwert der Stromaufnahme inner- 
halb des einzelnen Zustands ermittelt, um das Signal für eine Bewertung zu glätten. 

Stellt man die erhaltenen Mittelwerte in Abhängigkeit von der Zeit grafisch 
dar, erhält man das in Abbildung 36 dargestellte Diagramm für MQTT und in 
Abbildung 35 eine Darstellung für HTTP. Es ist zu erkennen, dass die Mittelwerte 
zwischen den Messzyklen leicht schwanken. Im Vergleich der beiden Diagramme 
von MQTT und HTTP wird ersichtlich, dass in der gleichen Zeitspanne von 500 s 
mit HTTP ein Messzyklus mehr durchgeführt werden kann. Weiterhin fällt die 
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Abb. 34 Stromaufnahme im Zeitverlauf des Sensorknotens mit MQTT-Messprogramms 


Stromaufnahme HTTP mit Mittelwerten 


Strom in [mA] 


0 50 100 150 200 250 300 350 400 450 500 
Zeit in [s] 


Abb. 35 Diagramm mit Mittelwerten der Stromaufnahme über einzelne Betriebszustände 
des HTTP-Programms 


unterschiedliche Stromaufnahme auf, die im Sendebetrieb bei der MQTT-Messung 
etwa 20 mA unter der von HTTP liegt. 

Die Tabelle in Anhang 6 zeigt die Mittelwerte der Stromaufnahme und die Dauer 
der Betriebsmodi eines jeden Messzyklus für MQTT. Anhang 7 stellt diese Werte 
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Abb. 36 Diagramm mit Mittelwerten der Stromaufnahme über einzelne Betriebszustände 
des MQTT-Programms 


Tab.6 Dauer Betriebszustände und durchschnittliche Stromaufnahme des Sensorknotens 
für Messprogramm mit HTTP und MQTT 


HTTP MQTT 
Dauer in Stromaufnahme Dauer in Stromaufnahme 
Betriebszustand [s] in [mA] [s] in [mA] 
Grundzustand 5.32 90.57 6.41 76.57 
Sendebetrieb 15.27 121.33 17.08 103 
Sleep-Modus 9.55 22.32 9.46 18.89 


für HTTP dar. Aus den Werten der einzelnen Messzyklen wurde anschließend ein 
Mittelwert für jeden Betriebszustand gebildet. Es ergeben sich die in der folgenden 
Tabelle 6 dargestellten Werte. 

Die Gegenüberstellung in Tabelle 6 zeigt, dass anders als erwartet keine Ver- 
kürzung der Sendedauer durch den Einsatz von MQTT erreicht werden konnte. Die 
Dauer des Sendebetriebs liegt bei MQTT mit durchschnittlich 17,08 s über der von 
HTTP mit 15,27 s. Allerdings ist die Stromaufnahme des Sensorknotens gesunken. 
Berechnet man mit 


Q=lst [24] (6.13) 


Q .. elektrische Ladung (Elektrizitätsmenge) 
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Tab. 7 Ermittlung der elektrischen Ladung je durchschnittlichen Messzyklus 


HTTP MQTT 
Stromauf- elektr. Stromauf- elektr. 
Dauer nahme in Ladung Dauer nahmein Ladung 
Betriebszustand in [s] [mA] in [mAs] in [s] [mA] in [mAs] 
Grundzustand 5.32 90.57 481.83 6.41 76.57 490.81 
Sendebetrieb 15.27 121.33 1852.71 17.08 103 1759.24 
Sleep-Modus 9.55 22.32 213.16 9.46 18.89 178.70 
Summe 2547.70 2428.75 


Tab.8 Berechnung Anzahl Messzyklen je Akkuladung 


HTTP MQTT 
elektr. Ladung in [mAs] 2547.70 2428.75 
je Messzyklus 
elektr. Ladung in [mAh] 0.7077 0.6747 
Anzahl Messzyklen je Akkuladung (2500 mAh) 3533 3706 


die elektrische Ladung Q je durchschnittlichen Betriebszustand, erhält man die in 
Tabelle 7 dargestellten Werte. Je Messzyklus konnte It. den Messwerten durch das 
MOTT-Messprogramm eine Verringerung der Elektrizitätsmenge um 5% erreicht 
werden. 

Eine Akkuladung der in Abschnitt 3.1.3 vorgestellten Energieversorgung des 
Sensorknotens enthält eine Elektrizitätsmenge von 2500 mAh. Es ergibt sich unter 
der idealisierten Annahme der vollständigen Ausnutzung der gesamten Kapazität 
des Akkus die in Tabelle 8 abgebildete Anzahl möglicher Messzyklen je Akkuladung. 
Mit dem Einsatz des MQTT-Messprogramms sind 173 Messzyklen mehr möglich. 
Dies entspricht einer Steigerung um 5%. 

Stellt man die in Tabelle 6 abgebildeten Werte in Form eines Lastprofils für einen 
durchschnittlichen Messzyklus des Sensorknotens dar, erhält man die Abbildung 37. 
Es sind die Betriebszustände Sleep-Modus, Grundzustand und Sendebetrieb erkenn- 
bar. Im Grundzustand wird das in Kapitel 5.1 vorgestellte Initialisierungsskript 
ausgeführt, im Sendebetrieb das Messskript. Im Vergleich der beiden Lastprofile 
des Sensorknotens mit HTTP- sowie MQTT-Messprogramm wird deutlich, dass die 
angestrebte Verkürzung der Sendedauer nicht realisiert werden konnte, die Strom- 
aufnahme im Sendebetrieb aber um etwa 20 mA gesunken ist. 

Die in Tabelle 1 dargestellte Stromaufnahme von 250 uA bei 3 V im Sleep-Mo- 
dus kann mit diesem Messaufbau nicht erreicht werden. Die beiden Spannungs- 
wandler und auftretende Verluste durch den gesteckten Schaltungsaufbau verursa- 
chen einen Strom von etwa 20 mA im Sleep-Modus und wurden in Kapitel 3.4 nicht 
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Abb. 37 Lastprofil Sensorknoten 


berücksichtigt. Allein der auf dem Entwicklerboard integrierte Spannungswandler 
verbraucht laut Datenblatt [62] 6 bis 10 mA. Für einen Aufbau mit möglichst langer 
energetischer Lebensdauer müsste ein fester Verbau der Komponenten und ein Ver- 
wenden von im Ruhezustand ebenfalls abschaltbaren Spannungswandlern erfol- 
gen. Nimmt man an, dass dadurch im Sleep-Modus eine Stromaufnahme des Sen- 
sorknotens von 250 pA ermöglicht wird, ergibt sich die im Folgenden abgeschätzte 
energetische Lebensdauer für HTTP und MQTT. Es wurde analog zu Kapitel 3.4 von 
einer stündlichen Messung ausgegangen. 

Analog zu Tabelle 7 wurde in Tabelle 9 die Elektrizitätsmenge eines durch- 
schnittlichen Messzyklus bei einer stündlichen Messung ermittelt. Die Dauer des 


Tab.9 Ermittlung der elektrischen Ladung je durchschnittlichem Messzyklus bei stündlicher 


Messung 
HTTP MQTT 
Stromauf- elektr. Stromauf- elektr. 
Dauer nahme in Ladung Dauer nahme in Ladung 
Betriebszustand in [s] [mA] in [mAs] in [s] [mA] in [mAs] 
Grundzustand 5.32 90.57 481.83 6.41 76.57 490.81 
Sendebetrieb 15.27 121.33 1852.71 17.08 103 1759.24 
Sleep-Modus 3579.41 0.25 894.85 3576.51 0.25 894.13 


Summe 3229.39 3144.18 
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Sleep-Modus beträgt nicht wie in Tabelle 7 etwa 10 s. Sie ergibt sich nun aus der Dif- 
ferenz zwischen einer Stunde und der Zeit, die für Grundzustand und Sendebetrieb 
benötigt werden. Anschließend wurde in Tabelle 10 diese Elektrizitätsmenge auf 
eine Woche hochgerechnet, in der 168 stündliche Messungen durchgeführt werden. 

Aus Abbildung 16 kann entnommen werden, dass der Vibrations-Harvester je 

ne 23 soya e 

Woche Tag Woche 
Zwischen elektrischer Ladung und Energie besteht der folgende Zusammenhang. 


bereitstellt. 


Woche eine Energiemenge von k 


W=Q*U (6.14) 
Ww .. Elektrische Energie/Arbeit 


Der zur Energieversorgung des Sensorknotens eingesetzte Lithium-Polymer-Akku 
besitzt eine Kapazität von 2500 mAh (= 9000 As). Bei einer Nennspannung von 3,7 
V ergibt sich eine Energiemenge des Akkus von (9000 As * 3,7 V =) 33.300 Ws. Es 
wird weiterhin von der idealisierten Annahme der vollständigen Ausnutzung der 
gesamten Kapazität des Akkus ausgegangen. Die Stromaufnahme des Sensorkno- 
tens wurde bei einer Versorgungsspannung von 5 V ermittelt. Es ergibt sich die fol- 
gende Tabelle 10. Diese zeigt, dass der Sensorknoten sowohl mit HTTP als auch mit 
MQTT mehr Energie aufnimmt, als der Harvester aus der Umgebung „erntet“. Divi- 
diert man die durch den Akku bereitgestellte Energiemenge von 33.300 Ws durch 
diese entstehende Differenz, ergibt sich eine energetische Lebensdauer von etwa 87 
Wochen bei MQTT und von 73 Wochen bei HTTP. Der Sensorknoten lässt sich durch 
den Einsatz von MQTT etwa 14 Wochen länger betreiben. 


Tab. 10 Ermittlung der energetischen Lebensdauer des Sensorknotens 


HTTP MQTT 


elektr. Ladung Q je Woche (stündliche Messung) in [As] 542.5 528.2 
Energiespeichervermögen Akku in [Ws] 33300 
Verbraucher Sensorknoten 2712.7 2641.1 
Energiemenge W je Woche in [Ws] Harvester 2257.5 
Differenz Verbraucher - Harvester 455,2 383.6 
energetische Lebensdauer in [Wochen] 73.2 86.8 


Die durchgeführten Betrachtungen zeigen, dass durch den Einsatz von MQTT eine 
Steigerung der Energieeffizienz des Sensorknotens eingetreten ist. Diese ergibt sich 
im Gegensatz zu den Erwartungen nicht aus der Reduzierung der Sendedauer, son- 
dern aus einer Verringerung der Stromaufnahme. 
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6.3 Nachbetrachtungen 


MOTT bietet als Protokoll zur Übertragung von Sensordaten Vorteile. Die größte Ver- 
besserung von MQTT ist die dauerhaft bestehenbleibende Verbindung, welche nicht 
wie bei HTTP nach einer gewissen Zeit oder Menge an übertragener Nachrichten, 
wie in Kapitel 3.2 beschrieben, unterbrochen werden muss. Der Neuaufbau einer 
Verbindung entspricht dem Betriebsmodus Grundzustand und nimmt It. Tabelle 6 
bei HTTP durchschnittlich 5,32 s ein. Weitere Vorteile bestehen in der Publish/ 
Subscribe-Logik und in der geringen vom Protokoll verursachten Datenmenge je 
Nachricht. Es wird eine streaming- und echtzeitfähige Kommunikation ermöglicht. 

Es konnte durch den Einsatz von MQTT anstatt von HTTP keine Reduzierung 
der Sendedauer, aber durch Verringerung der Stromaufnahme eine Senkung der je 
Messzyklus benötigten Elektrizitätsmenge von 5% und damit eine Verlängerung der 
energetischen Lebensdauer des Sensorknotens erreicht werden. 

Es wurde zur Messdurchführung der identische Aufbau mit denselben Hard- 
warekomponenten verwendet. Die Entfernung zum RPI als Router blieb ebenfalls 
konstant. Zunächst erfolgte die Messung des MQTT-Programms. Anschließend 
wurde auf dasselbe Transceivermodul das HTTP-Messprogramm aufgespielt. Eine 
hardwarebedingte Änderung der Stromaufnahme könnte durch einen Temperatur- 
drift infolge der andauernden Verwendung des Moduls eingetreten sein. Eine Ver- 
änderung in der eingetretenen Größenordnung von etwa 20 mA scheint allerdings 
aus diesem Grund nicht plausibel. Eine Verringerung der Stromaufnahme durch 
den Einsatz von MQTT anstatt HTTP ist zudem ebenfalls in der in [47] dargestellten 
Untersuchung eingetreten. 

Im Betriebsmodus Grundzustand wird das Initialisierungsskript ausgeführt. 
Die Verlängerung des Grundzustandes durch MQTT kann darauf zurückgeführt 
werden, dass im Initialisierungsskript der Aufruf des Messskriptes erfolgt. Es wer- 
den das Messskript und die zur Ausführung benötigten Bibliotheken geladen. Sind 
diese bei MQTT umfangreicher als bei HTTP, wird mehr Speicherplatz in Anspruch 
genommen und eine größere Aufrufedauer verursacht. Aufgrund der durchgeführ- 
ten Betrachtungen erscheint das ermittelte Lastprofil mit der Verringerung der 
Stromaufnahme und der Verlängerung des Grundzustandes durch MQTT plausibel. 

Mit den folgenden Überlegungen wird untersucht, wie sich die Zeitdauer des 
Zustandes Sendebetrieb zusammensetzt. Ein Teil der Zeit entsteht durch den Mess- 
vorgang, welcher etwa 0,7 sin Anspruch nimmt. 

Nachdem der Sensor die Messung durchgeführt und die Messwerte in den Zwi- 
schenspeicher geschrieben hat, erfolgt die schrittweise Übertragung dieser Werte 
über die SPI-Verbindung zwischen Sensor und Microcontroller. Abbildung 38 zeigt 
die Funktionen, die bei einem einzelnen Auslesevorgang ablaufen. 

Zu Beginn wird die in der Abbildung 38 links dargestellte Funktion „read_reg“ 
aufgerufen. Diese wiederum ruft mit der ersten Zeile die rechts abgebildete Funk- 
tion „SET_CS“ auf, welche mit dem „tmr.delay“ zweimal den weiteren Programmab- 
laufs für 15us anhält. Anschließend wird die erste 16-Bit-Sequenz an den Sensor 
übertragen. Mit dieser erfolgt das Anschreiben der Adresse des Zwischenspeichers 
des Sensors, in dem sich die Messwerte befinden. Im Anschluss wird eine sog. 16-Bit 
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gpio.ı 


Abb. 38 Funktionen zum Auslesen des Sensors 


Dummy-Sequenz gesendet, welche ausschließlich aus Nullen besteht. Nachdem 
eine 16-Bit-Sequenz übertragen wurde, wird ein „delay“ von 15us programmiert. 
Diese Unterbrechung ist notwendig und wird vom Hersteller empfohlen, um Fehl- 
kommunikationen zu vermeiden. Wird eine 16-Bit-Sequenz an den Sensor übermit- 
telt, erhält das Transceivermodul zur gleichen Zeit eine Sequenz auf dem anderen 
Datenkanal vom Sensor zurück. 

Zählt man alle aufgerufenen „delays“ der in Abbildung 38 dargestellten Funkti- 
onen zusammen, werden dadurch je Auslesevorgang 6 * 15 us = 90 usin Anspruch 
genommen. Um die Dauer eines gesamten Vorgangs zu ermitteln, muss dazu die Zeit 
addiert werden, welche die Datenübertragung über die SPI-Verbindung verursacht. 
Es erfolgt je SPI-Datenkanal eine Übermittlung von zwei 16-Bit-Sequenzen mit insge- 
samt 32 Bit. Der Sensor besitzt eine Taktrate von 2,25 MHz, der Microcontroller von 
80 MHz. Die Taktfrequenz der SPI-Verbindung darf maximal so hoch sein, wie die 
des schwächeren Teilnehmers. Zur Konfiguration der SPI-Verbindung im Messskript 
wird ein sog. Clock-Devider angegeben, welcher die Taktrate des Transceivermo- 
dul durch eine 2er-Potenz teilt. Die größtmögliche Taktfrequenz der SPI-Verbindung 


80 MHz 


beträgt mit diesen Randbedingungen = 1,25 MHz. Das bedeutet, dass jede 


Sekunde 1.250.000 Bit je Datenkanal übertragen werden können. Für einen Ausles- 
32Bit 
1.250.000 


evorgang müssen je Kanal 32 Bit übertragen werden, sodass = 25,6us 


benötigt werden. Zusammen mit den „delays“ des Programms ergibt sich für einen 
einzelnen Auslesevorgang damit die folgende Zeitdauer: 90 us + 25,6 us = 115,6 us. 
Für 3072 Auslesevorgänge des eigentlichen Messprogramms beträgt die Zeit- 
dauer 3072 * 115,6 us = 355,1 ms. Die Zeitdauer der Datenübertragung mittels SPI-Ver- 
bindung ließe sich durch Einsatz eines Sensors mit der gleichen Taktfrequenz von 


80 MHz wie die des Microcontrollers auf3072*| 9Qus „Bit =3072*(90us+ 
80.000.000 2 


0,4 us) = 277,7 ms reduzieren. Diese Betrachtung zeigt, dass die Datenübertragung 
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mittels SPI-Verbindung mit etwa 0,35 s nur einen kleinen Teil der Dauer des Zustan- 
des Sendebetrieb einnimmt. 

Es wird vermutet, dass der größte Anteil der restlichen Zeitdauer des Sendebe- 
triebs nicht auf den reinen Versand der Nachrichten entfällt. Es wurde deshalb das 
folgende Testszenario entwickelt, in dem ebenfalls eine Messung von 3072 Werten 
durch den Sensor und ein Versand von 24 Nachrichten mit je 128 Werten vom Tran- 
sceivermodul erfolgt. Der Unterschied zu dem in Kapitel 6.2 verwendeten Messpro- 
gramm liegt in der Anzahl an Auslesevorgängen je erstelltem Datenpaket. Es wird 
insgesamt je Paket nur ein Wert ausgelesen und auf dem Microcontroller zwischen- 
gespeichert. Dieser einzelne Messwert wird 128 Mal hintereinander zu einem String 
zusammengefügt, sodass die Datenmenge einer übertragenen Nachricht identisch 
mit der Messung in Kapitel 6.2 ist. 

Es wurde zur Ermittlung der Sendedauer analog zu Kapitel 6 vorgegangen und 
ebenfalls ein Zeitraum von etwa 500 s betrachtet. Es ergeben sich für einen Ablauf 
des veränderten Messprogramms die in Tabelle 11 abgebildeten Mittelwerte. 


Tab. 11 Betriebszustände bei einmal Auslesen je Datenpaket für HTTP und MQTT 


HTTP MQTT 
Dauer in Stromaufnahme Dauer in Stromaufnahme 
Betriebszustand [s] in [mA] [s] in [mA] 
Grundzustand 5.34 117.78 6.39 117.96 
Sendebetrieb 4.15 160.95 3.3 160.92 
Sleep-Modus 9.39 29.51 9.43 29.94 


Im Vergleich mit den Werten der Messprogramme in Tabelle 6 fällt auf, dass die 
Dauer des Zustandes Sendebetrieb bei HTTP wie auch bei MQTT erheblich reduziert 
wurde. Anstatt 17,08 s beträgt die Sendedauer mit MQTT nur noch 3,3 s, eine Diffe- 
renz von 13,78 s. Im Gegenzug stieg die Stromaufnahme um etwa 40 mA bei HTTP 
und 60 mA bei MQTT auf 161 mA an. Die Sendedauer des MQTT-Messprogramms ist 
mit 3,3 s 0,85 s geringer als die des HTTP-Programms mit 4,15 s. 

Das Szenario zeigt, dass nicht der reine Sendevorgang die größte Zeitdauer in 
Anspruch nimmt, sondern das schrittweise Auslesen und Zwischenspeichern der 
Messwerte in einer Tabelle sowie das Erstellen der Zeichenkette mit 128 unter- 
schiedlichen Werten. Eine Reduzierung der für das Versenden der Nachrichten 
benötigten Zeitdauer besitzt damit kaum Einfluss auf die Dauer des Zustandes Sen- 
debetrieb. Prinzipiell konnte durch den Einsatz von MQTT eine Verringerung der 
Sendedauer erreicht werden kann. 


7 Zusammenfassung und Ausblick 


In dieser Bachelorarbeit wurde eine kommunikationstechnische Optimierung 
eines bestehenden funkbasierten Sensorkonzepts mit dem Ziel der Steigerung der 
Energieeffizienz durchgeführt. Es erfolgte zunächst eine Analyse des vorhandenen 
Sensorkonzepts, auf deren Grundlage Optimierungspotentiale erarbeitet wurden. 
Durch das Ersetzen des bisher verwendeten Anwendungsprotokolls HTTP durch das 
leichtgewichtige MQTT entstand ein alternatives Sensorkonzept. Es sollte die Dauer 
des Sendevorgangs verringert werden, welche maßgeblich die Stromaufnahme des 
Sensorknotens bestimmt. 

Es wurde ein Messszenario entwickelt, welches einen quantitativen Vergleich 
des bisherigen mit dem überarbeiteten Sensorkonzept ermöglicht. Die Stromauf- 
nahme des Sensorknotens wurde inklusive eines Zeitsignals mit Hilfe eines Mess- 
widerstands und einer sich anschließenden Signalerfassungsschaltung erfasst. Aus 
diesen Daten konnte das Lastprofil des Sensorknotens erstellt und verglichen wer- 
den. Dieses Messkonzept kann zudem zur Bestimmung eines Lastprofils zukünfti- 
ger Messaufbauten verwendet werden. 

Eine Reduzierung der Sendedauer konnte durch den Einsatz von MQTT anstatt 
von HTTP nicht erreicht werden. Es wurde aber eine Verringerung der Stromauf- 
nahme erzielt, wodurch die Energieeffizienz des Sensorknotens gesteigert wurde. 
MOTT bietet als Protokoll zur Übertragung von Sensordaten weitere Vorteile. Diese 
bestehen u.a. in der geringen vom Protokoll verursachten Nachrichtengröße sowie 
in der dauerhaft bestehenbleibenden Verbindung ohne Timeouts, wodurch eine 
streaming- und echtzeitfähige Kommunikation ermöglicht wird. 

Von weiteren Interesse ist eine programmiertechnische Optimierung des LUA- 
Messkripts, in welches MQTT implementiert wurde, da theoretisch zumindest eine 
geringe Reduzierung der Sendedauer hätte eintreten müssen. Es ist zu hinterfragen, 
ob alle dort ausgeführten Programmzeilen tatsächlich benötigt werden. 

Eine weitere Optimierungsmöglichkeit besteht im Einsatz eines Microcontrol- 
lers der aktuellen Generation. Das Nachfolgemodell „ESP32“ des in dieser Bachelor- 
arbeit verwendeten Transceivermoduls „ESP8266“ besitzt einen schnelleren Prozes- 
sor mit einer Taktfrequenz von 240 MHz sowie mit 512 kByte einen etwa zehnmal 
größeren Arbeitsspeicher. Es ist eine schnellere Programmausführung zu erwar- 
ten. Zudem ermöglicht es der größere Arbeitsspeicher bspw. 1072 Messwerte in 
einem Feld mit mehreren Spalten auf dem Microcontroller zwischenzuspeichern. 
Anschließend könnte ein spaltenweises Zusammenfügen der Werte zu einem String 
und ein darauffolgendes Versenden des Datenpakets erfolgen, wovon eine Reduzie- 
rung der Ausführungsdauer erwartet wird. 

Die durchgeführte Nachbetrachtung zeigt, dass durch den Einsatz von MQTT 
anstatt von HTTP unter anderen Bedingungen als denen des Sensorkonzepts eine 
Reduzierung der Sendedauer erreicht werden kann. Eine Verwendung von MQTT 
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in zukünftigen Konzepten mit funkbasierter Datenübertragung bietet sich deshalb 
und vor allem zur Übertragung kleiner Datenpakete oder Einzelwerte aufgrund der 
oben genannten Vorteile an. 

Ein weiterer Ansatz besteht bei der Umsetzung zukünftiger Konzepte in der 
grundsätzlichen Änderung des Sensorkonzepts. Bspw. könnte auf dem Microcont- 
roller eine Berechnung von Diagnosekennwerten durchgeführt werden. Anstatt aller 
Messwerte würde die versendete Nachricht dann nur z.B. einen Begriff zur Zustand- 
seinschätzung enthalten. Alternativ ist auch denkbar, dass nur beim Auftreten kriti- 
scher Werte eine Nachricht erstellt und versendet wird. Der Vorteil dieser Variante 
besteht darin, dass weniger und kürzere Nachrichten übermittelt werden müssten. 

In dieser Bachelorarbeit wurde auf der Leitwarte zum Loggen der Messwerte 
in eine CSV-Datei die Software Node-Red eingesetzt, welche eine datenflussbasierte 
Programmierung ermöglicht. Es ist darüber hinaus eine Umsetzung der Funktiona- 
litäten der auf der Leitwarte ausgeführten Matlab-Applikation mit Node-Red denk- 
bar. Die auf einem sog. Dashboard angezeigten Informationen können über eine 
URL-Adresse von jedem beliebigen Gerät mit einem Webbrowser wie bspw. einem 
Smartphone oder Laptop aufgerufen werden, welches sich im gleichen Netzwerk 
befindet. Es wird eine Datenanzeige ohne Einrichten eines Programms auf diesen 
externen Geräten ermöglicht. 

Der Einsatz von Node-Red könnte sich in zukünftigen Aufbauten ebenfalls 
anbieten. Mit dem Dashboard könnte zudem nicht nur eine Anzeige, sondern auch 
eine Eingabe von Informationen erfolgen. 
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Anhang 1 LUA-Code Initialisierungsskript 


krial 

station_cfg={} 

station_cfg. "MOTT-Pi" 
station_cfg. redraspberry" 
wifi.sta.config(station_cfg) 
wifi.setmode(wifi.STATION) 
wifi.sta.connect() 


tmr.alarm(1, 1888, 1, function() 


if wifi a.getip() == and trial <= 18 then 
trial = trial + 1 
print ("IP unavailable, Waiting..."..trial) 


if trial > 10 then 
node.dsleep(68 * 1980020) 


end 


else 


tmr.stop(1) 


‘fail ie Oe === Ses === zii) 
print("E is: " .. wifi.getmode()) 
print("MAC adress GOWL: .getmac()) 
print("IP is 


dofile("188502.1lua") 
end 


end) 


Anhang 2 LUA-Code Messskript 


(1, spi.MASTER, spi.CPOL_HIGH, spi.CPHA_HIGH, 16, 64, spi.FULLDUPLEX); 
(pin, gpio.OUTPUT) 

(rdy, gpio.INPUT) 

e(pin, gpio.LOW) 


function read d val(PIN, values, address, 


local array = {} 


if bit.band(read_reg(PIN, @ @ and read_ ð s= @xFFFF then 


for i = 1, values do 
local byte _reg(PIN, address) 


array[i] = string. + byte) 
end 


local a = table.concat(array, ) 
S ng(a, values, filter[1]) 


value, index, band) 
local data = value.. 
m:publish( ‚ data, 
function(client) 


en() end, 


function(client, reason) print( ..reason) end) 


function t 
local 


t(t,1,rest) 
num=(num-rest)/2 
end return table.concat(t) 


end 


function SET_CS(PIN) 
(PIN, gpio.LOW) 
‚(15) 
(PIN, gpio.HIGH) 


function read_reg(PIN, address) 
(PIN) 
spi nd(1, address); 
tor y(15); 
wrote, hi_byte = spi 
SET_CS(PIN) 
hi_byte 


return data; 


function write_reg(PIN, address) 
S(PIN) 
(1, address) 
(PIN) 
(15) 


function wait() 
while gpio.read(rdy) == 1 do 
gpio.read(rdy) 
tmr.delay(1®) 
end 


function in 
filter = 


filter[1]) 


4 / ANZ then 


end_val(pin, ANZ, axis[l], filter[1]) 


ite_reg(pin, 8 
 reg(pin, ®xB 


d val(pin, ANZ, axis[1], filter[1]) 


mgtt.Client( 


m:on( » function(client) 
1 ) 


4 
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Anhang 3 Node-Red Programmfluss zum 
Loggen der Messdaten in eine CSV-Datei 


Anhang 81 


Anhang 4 Messskript Arduino 


int ADC1=1; 
int value; 
float strom=0; 


void setup() { 
// put your setup code here, to run once: 
Serial.begin (9600); 
Serial.println("Zeit, Strom"); 

} 


void loop() { 
// put your main code here, to run repeatedly: 
value = analogRead (ABC1); 
strom = (5.0 / 1024.0) * value / 11.0499 / 1.2; 
Serial.print (millis());| 
Serial.print("”,"); 
Serial.printin(strom, 3); 
delay (100); 
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Anhang 5 grafische Darstellung der HTTP- 
Messwerte 


Stromaufnahme mit HTTP 


Strom in [A] 


0 100000 200000 300000 400000 500000 
Zeitdauer in [ms] 


Anhang 83 
Anhang 6 Mittelwerte der Betriebsmodi der 
einzelnen Messzyklen mit MQTT 
Messung Grundzustand Senden 
Zeitin Strom in Zeitin Stromin Zeitin Stromin 
[s] [mA] [s] [mA] [s] [mA] 
1 9.37 19.02 6.45 76.83 16.83 102.37 
2 9.68 19.78 6.25 76.08 16.93 103.35 
3 9.68 19.90 6.25 76.97 17.14 102.65 
4 9.38 18.32 6.35 76.56 17.24 102.58 
5 9.58 19.01 6.75 76.00 17.24 103.45 
6 9.38 18.65 6.55 77.53 16.94 102.91 
7 9.48 18.55 6.45 76.40 17.04 103.04 
8 9.48 18.98 6.35 77.42 17.14 102.24 
9 9.38 18.67 6.45 11,39 17.04 104.01 
10 9.48 19.63 6.25 76.61 17.14 104.05 
11 9.38 18.38 6.45 76.25 17.04 102.04 
12 9.48 19.07 6.45 11.25 17.24 102.76 
13 9.48 18.34 6.45 75.45 17.04 102.89 
14 9.48 18.67 6.25 76.52 17.24 102.96 
15 9.28 18.37 6.45 75.37 16.94 103.72 
Mittelwert 9.46 18.89 6.41 76.57 17.08 103.00 
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Anhang 7 Mittelwerte der Betriebsmodi der 
einzelnen Messzyklen mit HTTP 


Messung Sleep Grundzustand Senden 
Zeitin Strom in Zeitin Stromin Zeitin Stromin 
[s] [mA] [s] [mA] [s] [mA] 

1 9.57 22.17. 5.24 91.66 15.22 120.23 
2 9.57 22.05 5.24 91.21 15.12 124.01 
3 9.68 22.02 5.34 92.09 15.02 121.45 
4 9.48 22.05 5.34 91.19 15.43 121.03 
5 9.48 21.79 5.34 89.61 15.43 121.55 
6 9.58 22.76 5.24 91.02 15.22 119.45 
i 9.48 20.67 5.24 90.24 15.22 120.19 
8 9.58 22.50 6.65 98.92 13 126.02 
9 9.68 23.38 5.24 89.94 15.23 121.15 
10 9.48 22.35 5.34 90.72 15.23 121.44 
11 9.68 23.34 5.24 91.08 15.33 120.88 
12 9.48 21.92 5.34 88.63 15.23 122.41 
13 9.48 22.11 5.24 90.49 15.43 121.01 
14 9.58 22.81 5.45 91.15 15.13 122.90 
15 9.58 24.54 5.34 89.69 15.63 121.29 
16 9.48 21.39 5.45 90.45 15.12 121.47 
17 9.48 21.77 5.45 89.95 15.43 120.89 
18 9.48 21.48 5.24 92.44 13.41 120.91 
Mittelwert 9.55 22.32 5.32 90.57 15.27 121.33 


Anmerkung: Die grau markierten Messungen 8 und 18 wurden nicht in die Mittelwert- 
bildung miteinbezogen, da die Zeitdauern des Betriebszustands Senden unplausibel 
sind. Vermutlich enthielten Teile der übermittelten Daten Fehlercodes anstatt Mess- 
werte, welche sich vom Transceivermodul schneller auslesen lassen. 


